Jump to content
Flirc Forums

Cru

Members
  • Posts

    12
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Cru's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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
  2. Sure. :) Both problems remain: 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. 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.
  3. 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.
  4. 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).
  5. HI @jason, I enabled IR debugging and recorded a few seconds, log attached. When I hold my hand between notebook screen and Flirc, the output stops. Best regards, // Veit my_flirc_log.txt
  6. 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
  7. 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! :)
  8. Use this guide to derive the HID page and key code of an HID event device or original remote connected e.g. via USB, I2C or Bluetooth to a Linux PC, or to verify that your Flirc actually sends the events you expect. HID page and key 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 a 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 requires root) using "sudo evtest [--grab<] <device>" for each device required. The optional parameter "--grab" is essential if you want to stop the recorded events to be forwarded to and interpreted by the system, like I did to stop my system going into standby whenever I sent the sleep event that I wanted to record. If you want to use "--grab" on your local keyboard or such, you might want to either attach a second keyboard or run the command over the network via SSH, so you can abort the monitoring by sending Ctrl+C. 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 representation 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 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.
  9. 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). 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!
  10. Hi Jason, thanks for the hint, but the suspend button does not emit HID page 0x07 code 0xf8, thus does not work for my purpose. :(
  11. 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?
  12. 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.
×
×
  • Create New...