kalhimeo

excellent finding, thanks a lot for your feedback !

Hi Jason and Yawor, Is there anything new, maybe with the new Flirc revision, to make the record api able to use codes above 255 in the "Consumer device (12)" table ? Could you maybe consider my suggestion for a future software update ? Or create a dedicated Flirc Profile for Android with buttons that cannot be mapped atm (ie. KEYCODE_SEARCH = HID 0x0c 0x0221) ? Thank you very much in advance. Best regards, Laurent

From my old notes (to be verified) : 402 KEYCODE_CHANNEL_UP -> 156 102 403 KEYCODE_CHANNEL_DOWN -> 157 102 362 KEYCODE_GUIDE -> 141 102 I don't have anything for DVR

as far as I remember, yes, that s the way ;-)

From my previous tests, I noted that these commands would start a search on my Nexus Player (to be used with flirc_util) : "8 105" (LWIN + F14) or "4 44" (ALT + SPACE) You may want to give them a try

You have to open a terminal and type the commands. On windows explorer, navigate to the flirc folder ( \Program files x86\flirc\) , maintain shift and right clic on an empty space. In the menu you should see "open commands here" (or something like that, my computer is not in english). You can now type the flirc_util commands in the terminal window which has just open

I played a bit more with the keycodes and the record_api command today. I have found the HID code for DPAD_CENTER, no need to use the KEYCODE_NUMPAD_5 trick anymore. The code is "0x0c 0x0041" which can be mapped via flirc using "65 102". It's really a pity that we can't use the full range of the "Consumer Devices" table, that would solve the HOME problem with the code "0x0c 0x0223" (virtually 547 102) without the need for root. Maybe jason could review a bit the handling of the basic HID codes: since there are only 231 characters in the table "7 - Keyboard/Keypad", could we use some codes from 232 to 255 as exceptions to fully cover the "12 - Consumer Devices" table ? For now you are using the code 102 (Keyboard Power) as an exception to send the first 255 HID codes via the modifier byte, but as we know, one byte is not enough to cover the 667 commands of the "12 - Consumer Devices" table. Could we imagine using the codes 253, 254 and 255 for this purpose ? Therefore "253" would cover HID commands from 0-255, "254" from 256-511, and "255" from 512 to 667. I think that this would make more sense than using the code 102. We could even imagine to cover more tables with the remaining numbers if needed. An other solution to fix the HOME button on Android TV only, would be to hard code a unique byte sequence which would reproduce "0x0c 0x0223". Thanks to the courageous readers who hold till the end ^^ Laurent

Hi there, I am facing the same situation as you guys, trying to take the most of my flirc to control my nexus player. I investigated how the Android key triggering system works, and I think that I pretty much understand why combinations like alt+esc works only in some programs, why it always work with the nexus remote, and what we need to achieve to have a fully working remote (even if I am not there yet). So the first thing Android does is to match a HID codes it receives to the related "Linux key code" (also called "scan code"), using the appropriate layout file which is stored in the "/system/usr/keylayout/xxxxxxx.kl" files. Each "Linux key code" will trigger an "Android key codename". In our case, Android will use the Generic.tl layout for the flirc because there is no specific file for it. An other example is the original remote of the nexus player which uses the "Nexus_Remote.kl" layout. Later on, we will see that we can create our own layout file for any input device by using its "Vendor ID" and "Product ID". I recommand you to have a look a this sample "Generic.kl" to better understand what .tl files are. When an "Android key codename" is triggered, it will also be interpreted according to the keychar file, which is stored in the "/system/usr/keychar/xxxxxxx.kcm" files. Most of the "Android key codenames" can result in a different action when used together with a key-modifier such as ctrl, alt, numlock, etc. Those additional actions are specified in the keychar file. Again, Android will use the Generic.kcm keychar in our case, and we could create our own keychar file using the device "Vendor ID" and "Product ID". Now to make the analyse complete, I have noticed that some Android applications like netflix or kodi will bypass the keychar file, and only the "Android key codenames" called in the layout file will be triggered. That's why a keyboard combination like alt+esc sometimes doesn t work, while in the same condition the original remote will trigger HOME flawlessly. So how can this help us ? First let's have a look at the "Generic.kl" file. Our main problem is to trigger the HOME and the DPAD_CENTER "Android key codenames" , which are the actions used by the original remote to go to home and perform a click which works with the virtual keyboard. By looking through the file, we can see the two "Linux key code" which correspond to those actions, respectively 172 and 353. Now we need to find which HID codes match those "Linux key codes". For that I found this table where the first row is the HID code in hexa, and the third is the "Linux Key Code", aka LKC, in hexa : - The LKC 172 makes "0x00ac", which match the HID code "0x0223" (547 in decimal) in the "HID Consumer Page 0x0c" (= table 12). - Unfortunately there is no match for the LKC 353 = "0x0161". BUT I found that we can use the "Android key codename" KEYCODE_NUMPAD_5 which, after processing through the keychar file, triggers DPAD_CENTER if the numlock is off (which seems to be by default). The LCK for this one 76 makes "0x004c" which match the HID code "0x005d" (decimal 93) in the "HID Keyboard and Keypad Page 0x07" (= table 7). Thanks to the flirc "record_api" command, we can record HID codes from the 7 and 12 HID tables, but we seem to be limited to a decimal value of 255 (at least in the 12th table, as stated by yawor above). A great new feature would be to simulate any HID code from any HID page via the flirc, without limitations ^^ So what else can we do ? Instead of reproducing complex HID codes to trigger existing LKC, we could simply modify the actions of the LKC in the layout file to trigger our own "Android key codenames". The flirc user "halfluck" already came up with this solution in this thread. The documentation to create a custom layout file is described here. We should duplicate the Generic.kl file and rename it to "Vendor_20a0_Product_0001.kl", then edit the action of some less used keyboard keys. For example, "key 35 H" could become "key 35 HOME", which would make any flirc record of keyboard key "h" triggers the home screen, whatever application is running in foreground. The only downside of this method is that you need root to modify the keylayout and keychar folders on Android. I have not rooted my nexus player yet, but I will keep you updated when I do ;-) If it works as expected, I will order my second flirc :-) In the meantime, I hope that this post helped some of you. Note that this method is not specific to the Nexus Player, it is valid for all Android versions. Best regards, Laurent

patchseven, when you try with the 1.1 beta firmware, you have to enable the feature via the command line utilities (this is not included in the GUI). It worked for my harmony 785.

A little post for info : I had noise problems with my flirc recording keys almost immediately without pressing any key, and after enabling the noise canceller from the last RC2, everything records now perfectly. Thank you very much Jason

very nice jason, that worked out ! I tried in a friend's laptop and also with an USB extender cable on the faulty laptop (to put the FLIRC away from the laptop usb port), both worked. I will now be able to do my first steps within FLIRC world, thank you very much ! PS: congrats to mum and dad ;-)

Thanks for your help Chris. I did not mention it here (only in the ticket support), but I already tried to overwrite the firmware v1 before the above test, with no luck :/

Since IR is direct sight line technology, my unit should not receive anything when I completely cover the FLIRC receiver. Anyway, I tried now in my underground garage just to be sure, that's more than 20m from any electronic source : same result, for any random key the FLIRC software still "learns" ghost IR signals. I am gonna send a message to the support now. Regards, Laurent

Yes that's what i did without success. I went to the toilet, no light, only the laptop with me, and I covered the FLIRC device completely with my hand. Then I started the software and the learn process was still detecting IR signals ! I repeated the process several times. The delay to detect ghost IR signals varied from immediate to a few seconds. It looks like my unit is defective :/

Hi, I found this thread while looking for help for my brand new FLIRC. I have similar issues with my unit (received last week) : when I try to record keys from the software, it will detect IR signals even when I don't press any key on my remote. I tried to put the laptop in a dark isolated room with no remote (just to be sure), and the same behaviour arises. I think that there may be a faulty batch. How can we proceed now ? Regards, Laurent