Cru Posted June 26, 2020 Report Share Posted June 26, 2020 (edited) 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 how to capture the required HID data for this key from BT further commands to try beside those from https://source.android.com/devices/input/keyboard-devices pages 0x07 und 0x0c how to encode further HID pages such as 0x01 generic system commands with flirc_util record_api 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 June 28, 2020 by Cru Added solution. Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.