Jump to content
Flirc Forums

Need help extracting a HID keycode


Cru

Recommended Posts

Hi,

I just bought a Flirc to finally get control over my Xiaomi Laser TV. It is an Android TV based projector that I currently control using a Harmony Hub via Bluetooth, but the BT connection is not reliably established, so this is where Flirc shall get into the game.

I was able to set up all keys using flirc_util recory_api and both the HID Keyboard/Keypad and Consumer pages from the Android documentation [ https://source.android.com/devices/input/keyboard-devices ] and the USB.oro and FreeBSD HID documentation except for the PowerOff button, that should put the device into standby mode. Unfortunately all the Power/Sleep/Coffee/Screenlock keycodes from the docs either let the shutdown menu pop up (which does not allow activating standby but only full system shutdown), or have no function.

So I tried adding a new "NVIDIA Shield" (not Shield TV) device, which emits the correct PowerOff command via BT, to the Harmony Hub and pair it with my Linux PC to try and extract the keycode using e.g. xev.

Unfortunately, sending this command to my PC via BT immediately puts it into sleep mode without logging any keypress, even after removing the corresponding keyboard bindings from the GNOME settings and systemd-logind.

Also issuing the PowerOn button only emits the character "0" (== keycode 102, which is used for all keycodes from HID page 0x0c), but not the required modifiers which encode the actual command on page 0x0c. So I have to assume that the PowerOff button will give me unuseful information, too.

Any help or hints on either

is greatly appreciated.

Thanks in advance!

 

UPDATE WITH SOLUTIONS TO MY REQUEST ABOVE (for anyone running into a similar problem):

HID page and code can be grabbed under Linux following these steps:

1. Find the event devices associated with your HID devices using "udevadm info -a <device>" with <device> walking through /dev/input/event*. There might be multiple devices for a single hardware component, e.g. for my Harmony Hub there is one for HID mouse events, one for HID keyboard events, one for HID consumer control events, one for HID system control events, ...

2. Monitor the desired event devices (usually needs root) using "evtest --grab <device>" for each device required. The parameter --grab is essential if you need to stop the recorded events to be forwarded to the system, like I did to stop my system going into standby whenever I send the sleep event that I want to record.

3. Perform the key presses on the device you want to record. Each key press will emit 2 events, one for key down (press), one for key up (release), example output for the "0" key:

Event: time 1593381762.020128, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70027
Event: time 1593381762.020128, type 1 (EV_KEY), code 11 (KEY_0), value 1
Event: time 1593381762.020128, -------------- SYN_REPORT ------------
Event: time 1593381762.020198, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70027
Event: time 1593381762.020198, type 1 (EV_KEY), code 11 (KEY_0), value 0
Event: time 1593381762.020198, -------------- SYN_REPORT ------------

4. Interpret the output; you are interested in the value of the MSC_SCAN (scancode) of EV_MSC (miscellaneous) events. The value is hexadecimal and for HID devices with the last 4 digits being the HID key code (0x0027) and leading digit(s) the HID page (0x07).

5. HID page 0x07 events (HID keyboard) can be programmed using "flirc_util record_api <modifiers> <key code>", where <key code> is the decimal interpretion of the HID key code you fetched above (e.g. 0x27 = 39), and <modifier> is a logical or-ed list of modifier keys to be held down while <key code> is sent (see "flirc_util help record_api").

I ran into an intentional limitation of flirc_util limiting <key code> to values <= 101. Unfortunately, flirc_util silently programs the key anyway without a warning, leaving a key that is never sent. This is what initially cost me a lot of time while trying to send the correct codes to my hardware, being the Flirc the culprit by never sending the programmed keys. Jason is currently checking whether the limitation will be removed.

Edited by Cru
Added solution.
Link to comment
Share on other sites

Using evtest I found out that the Harmony Hub emits HID page 0x07 code 0xf8 (KEY_SLEEP), thus using "flirc_util record_api 0 248" should record a key that emits this button press.

The key gets recorded by the command without any error or warning, but also using evtest I found out, that the button press is actually not emitted (nothing is emitted at all).

This is not limited to key code 248 but seems to be true for every key code >101. Is this a bug in flirc_util or in the Flirc firmware?

Link to comment
Share on other sites

no, it wouldn't be in the HID table, it would be in the consumer table, which is a valid system wide table for system control, and should work.

My keyboard report is limited to 101, artificially. I could extend this, but I would need to look into the impact. Anything above 231 is reserved.

Link to comment
Share on other sites

2 minutes ago, jason said:

no, it wouldn't be in the HID table, it would be in the consumer table, which is a valid system wide table for system control, and should work.

This is a thing that I already tried before posting this topic. It works in that way that it causes my projector to open the shutdown menu, which allows me only to perform a full system shutdown.

But what I want to do is putting it in standby, and I extracted the way how the Harmony Hub does this when using the "NVIDIA Shield" configuration (*not* "NVIDIA Shield TV") vial Bluetooth, which works but BT connection is unreliable. This configuration emits HID page 0x07 (keyboard) code 0xf8 (KEY_SLEEP).

2 minutes ago, jason said:

My keyboard report is limited to 101, artificially. I could extend this, but I would need to look into the impact. Anything above 231 is reserved.

At least key codes >101 / >0x65 are used widely for system control keys in keyboard page in both Linux and Android, according to Android's HID documentation:

https://source.android.com/devices/input/keyboard-devices

I assume that the Linux kernel devs did not make these codes up but derived them from real-world hardware.

In the basement I just found this wireless keyboard from Grundig whose USB receiver also emits page 0x07 code 0xf8 (KEY_SLEEP) instead of Sleep from the consumer page when pressing its standby button in the top right corner:

Event: time 1593216654.871345, -------------- SYN_REPORT ------------
Event: time 1593216656.276019, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700f8
Event: time 1593216656.276019, type 1 (EV_KEY), code 142 (KEY_SLEEP), value 1
Event: time 1593216656.276019, -------------- SYN_REPORT ------------
Event: time 1593216656.351066, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700f8
Event: time 1593216656.351066, type 1 (EV_KEY), code 142 (KEY_SLEEP), value 0
Event: time 1593216656.351066, -------------- SYN_REPORT ------------

So unlimiting flirc_util would be greatly appreciated. :)

Best regards!

signal-2020-06-27-031044.jpeg

Link to comment
Share on other sites

Hi @jason,

thank you very much!

I am new to Flirc, thus having a question on the upgrade process:

All my three Flircs seem Gen 1 devices, the SKU reported for all of them is "flirc", not "dori" or "nemo":

$ ./flirc_util version
3.25.3
FW Version: v3.11.0
   SKU:     flirc
   Hash:    0xA41ECA3A

The FW version (though the GUI tells me is the latest version) is one major off.

Is my assumption correct that both dori and nemo are Gen 2 devices, which run on FW 4 while "flirc" run FW 3?

If yes, could we please get a FW 3 with the HID code limit removed, too?

Thanks in advance and best regards! :)

Link to comment
Share on other sites

16 hours ago, Cru said:

Hi @jason,

thank you very much!

I am new to Flirc, thus having a question on the upgrade process:

All my three Flircs seem Gen 1 devices, the SKU reported for all of them is "flirc", not "dori" or "nemo":

$ ./flirc_util version
3.25.3
FW Version: v3.11.0
   SKU:     flirc
   Hash:    0xA41ECA3A

The FW version (though the GUI tells me is the latest version) is one major off.

Is my assumption correct that both dori and nemo are Gen 2 devices, which run on FW 4 while "flirc" run FW 3?

If yes, could we please get a FW 3 with the HID code limit removed, too?

Thanks in advance and best regards! :)

Yes, unfortunately this is a version 2 only feature. It definitely wont work on version 1 due to various limitations, and I have no intention on doing anything other than maintenance releases for gen1 devices.

Link to comment
Share on other sites

On 7/3/2020 at 12:53 AM, jason said:

It's not the CLI that needed to be updated, but the firmware

No guarantee this will break something else. I've updated the report ID so that you can go as high as 255. Try it and let me know.

 

dori.release-4.9.4.bin 60.69 kB · 1 download nemo.release-4.9.4.bin 60.81 kB · 0 downloads

Hi @jason,

I purchased a Flirc Gen. 2 Dori and it was delivered today. On it I installed your firmware, but it did not work; I still can record KEY_SLEEP using "flirc_util record_api 0 142", but nothing is being submitted when the bound remote button is pressed.

I suspect this is caused as the device only reports event type 1, event code 1..127 being supported, thus other codes might be ignored by the driver:

Input device ID: bus 0x3 vendor 0x20a0 product 0x6 version 0x101
Input device name: "flirc.tv flirc Keyboard"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 1 (KEY_ESC)
    Event code 2 (KEY_1)
...
    Event code 126 (KEY_RIGHTMETA)
    Event code 127 (KEY_COMPOSE)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Key repeat handling:
  Repeat type 20 (EV_REP)
    Repeat code 0 (REP_DELAY)
      Value    250
    Repeat code 1 (REP_PERIOD)
      Value     33
Properties:

Could you add code 142 (KEY_SLEEP) to this list for testing, please?

Furthermore I have the issue that my brand new Dori recognises something within my living room as IR input, which means for programming I need to shadow the Flirc so it only sees the remote that I want to program a key from. Also remote key presses are only detected reliably if I hold the IR LED of the remote directly (0-3cm) in front of the Flirc's sensor window or shadow it again.

None of my set of 3 Flirc Gen. 1 devices showed this behaviour, neither while recording nor while interpreting key presses. They just worked and recognised remote button presses no matter in which direction I pointed with the remote.

I have switched off or covered all artificial light sources in the room (projector, ambient lights, LED clock, harmony hub, keyboard illumination, internet router LEDs, ...). I am sitting in an almost completely dark room now, only some moon light thru the window and my notebook screen dimmed to minimum, but the problem persists. I suspect the notebook screen to be the cause, as even though it is dimmed to minimum and almost unreadable, the remote button recognition increases if I put my hand between screen and Flirc. It does not seem to be a PWM flanking issue, as turning the screen to maximum brightness (which I suppose to source the backlight without any PWM signal downs) almost completely kills remote button recognition even if I put the remote's LED in direct contact with the Flirc's sensor window.

Any help is appreciated.

Best regards,
// Veit

 

Link to comment
Share on other sites

I just found out that my notebook immediately wakes up from suspend if the Flirc is connected, but does not if I cover the Flirc.

Using this I found that the problem is not caused by my notebook's screen, but by the IR LED of the proximity sensor of my Samsung Galaxy S9, which is used to determine whether the always-on display shall be active (uncovered) or not (covered). The signal seems to have been reflected by the ceiling. Once I cover the phone's proximity sensor, the Flirc responds to remote button presses quite well, even if I direct the remote in the opposite direction (although subjectively it seems to be not as responsive as I experienced with the Flirc Gen 1 devices).

 

Link to comment
Share on other sites

2 hours ago, Cru said:

The signal seems to have been reflected by the ceiling.

 

The device laid on a low coffee table about 3m (~10ft) away from me, in the opposite direction of the Flirc sensor window, which is quite distant, I think.

The living room is ca. 65m² (~700sqft) with both white ceiling and floor, but coloured walls and dark furniture.

I did not experience any problems with IR controlled devices so far.

Link to comment
Share on other sites

Yeah that’s really interesting about the phone. I wouldn’t have suspected that. 
 

Sensitivity is the same. It’s the same sensor. A better algorithm. It’s not as responsive because it’s less “slippery”. It’s more consistent about button presses and when you let go real quick or when you are holding it down. 

i don’t follow the remaining problems. Can you summarize?

Link to comment
Share on other sites

Sure. :)
Both problems remain:

  1. Flirc (including Firmware 4.9.4) does not emit KEY_SLEEP (page 7, keycode 142), thus I cannot put by projector into standby as intended, and I suspect the reason is that the HID device "flirc.tv flirc Keyboard" does only announce code 1..127 to be supported.
  2. When my phone lays open in the same room, I am not able to reliably control the dori Flicr (or even have my notbook computer in suspend mode if Flirc is attached), as it goes bonkers over my phone's proximity sensor.
Link to comment
Share on other sites

On 7/8/2020 at 3:45 PM, jason said:

Nothing I can do about two. You need to learn without your phone present, and then it should work fine. Can you  confirm?

Hi @jason,

thank you very much. I can confirm this solved problem #2, but only after formatting and completely reconfiguring the Flirc.

Before formatting, it contineously woke my notebook when attached and the phone was in the room, and also IR reception was disturbed. I suppose that I accidentally bound a key to the proximity sensor noise that interfered, that does not emit a character, so I did not notice this.

Problem #1 remains unsolved.

Best regards,
// Veit

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...