foto808

It's not possible to bring up the multi-task menu because Flirc can't send the correct HID code for that button on the Shield remote. No amount of configuration with URC's or Flirc's software is going to change that. As I wrote above: The correct buttons for SHIELD to match every button on the included 2017 remote for both short and long press, are all from the HID Consumer Usage table - and none are gamepad buttons. Flirc's Shield profile doesn't use all these codes (only some) and can't use higher numbered ones with the current firmware, so it's impossible at the moment to mimic all the buttons properly.

I realize that the device has to declare itself as composite and include descriptors for all the usage tables it will support. But without the necessary consumer codes, the NVIDIA SHIELD control, for example, is only half-baked and will never work the way many customers would expect it to.

The correct buttons for SHIELD to match every button on the included 2017 remote for both short and long press, are all from the HID Consumer Usage table - and none are gamepad buttons. Flirc's Shield profile doesn't use all these codes (only some) and can't use higher numbered ones with the current firmware, so it's impossible at the moment to mimic all the buttons properly. Example: long-press of back button doesn't display power menu. Double-press home doesn't bring up task switcher. Both because incorrect keyboard codes are being used instead of the correct consumer HID codes. Incidentally, the functionality of the MIC/Voice button on the 2017 remote can be duplicated with Consumer code 0x221 A number of keyboards, including some from Logitech and Microsoft feature keys that use these consumer codes - they work perfectly to match NVIDIA's remote buttons in every situation, regardless of app/context.

Any traction on this? In my experience, while NEC works decently, it's still very slow - not sure if it's because it's not recognized at the protocol level, takes too long to hash or... But the result is that there's no comparison on the speed of native remote support and that translated through Flirc. I've found that other codes besides NEC aren't worth learning as the Flirc software just doesn't deal with them in a satisfactory manner at all, even the simple and well documented RC5.

The correct buttons for the Shield are all from the HID Consumer table (despite what NV seems to mention). The Search is 0x221 AC Search. This is not supported by the current Flirc software as it can't do any consumer codes above a certain number. If Flirc were updated to support all consumer usage table codes it would be a lot more versatile as a general purpose HID input device. There are many USB-enabled products that may still employ very custom HID solutions, but a composite device with keyboard & consumer at a minimum would do most everything posters here are interested in. This is a great suggestion: IMO, why stop there though. Full support for all (sensible) usage tables would be even better. Gaming device, LED, Generic desktop, simulation - this would require being able to set a lot more parameters than the current keyboard-only codebase allows.