Jump to content
Flirc Forums

jason

Administrators
  • Posts

    2,744
  • Joined

  • Last visited

  • Days Won

    118

Posts posted by jason

  1. 36 minutes ago, Patrick Kinne said:

    We are deploying 150+ mini Windows 10 PCs that display a whiteboard and TV web app in hospital patient rooms.  We built a configuration file for the USB dongle and include it in the deployment image, but have noticed that we have to manually apply the config file through the GUI whenever we install a box - is there a better way?

    1. Is the config file applied to the USB dongle itself? 
    2. Will it "stick" if I unplug the dongle and plug it into a new box that has the flirc software installed?
    3. Is there any way to automate this deployment so the config file can be applied on first plugin? We have the rest of the windows image/build automated.

    1. The config is applied to the dongle, not on the computer.

    2. Yes, it stays with the dongle when moved

    3. Yes, install on the destination machine, or you can reach out to me directly, and if planned together, you can purchase custom units pre-loaded in white label boxes.

  2. 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?

  3. 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.

  4. I dug into this more, it's a generic linux kernel bug.

    From: https://stackoverflow.com/questions/35728129/usb-hid-device-poll-interval-on-linux/36002731#36002731

    Quote

    Looks like this is because of a bug in Linux drivers for UHCI and some OHCI controllers. The driver doesn't process the TDs filled by the controller fast enough, so the controller must skip a SOH slot. As a result, interrupt transfers arrive only every second slot. If I insert USB 3.0 card into the same Linux, everything is fine because XHCI driver is used instead. If I run Windows on the same computer, everything is fine, because Windows doesn't have the bug.

    Another Reference

    Quote

    Note: This only shows the polling interval requested by the device and not the actual interval being used. See BBS.

    Report, this states there is a workaround, there is not.

    An official kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=60586 with a discussion on the topic: https://www.mail-archive.com/linux-usb@vger.kernel.org/msg24939.html

    I will not be changing the polling time in firmware to accommodate for this stupid linux bug. There is a way to change the polling time for specific USB devices, but mainly keyboards and mice. Flirc is a USB HID device, so there is no specific way to do the custom generic HID interface polling override. However, there seems to be a possible way to do it by patching the kernel: https://gitlab.freedesktop.org/panfrost/linux/commit/2ddc8e2d2b5902b376fee51585c8eed72b8836e7

    This may be the route I try. But it's not urgent, since the workaround is fairly easy, just set it up on another computer. But it looks like I can just compile a patched kernel module so we can override the poll time of flirc, include it in my package.

    Free upcoming product for anyone willing to put the time in to the above to get the poll time override working on generic HID devices.

  5. 13 hours ago, parkerlreed said:

    I'm hitting this on a Raspberry Pi 4 running Arch Linux ARM and my desktop. The unit appears to be working fine. I can record keys and the input works but flirc_util is throwing those errors. I made sure to clone the latest sdk and build flirc_util there in case anything changed/weird incompatibility with the system.

    ------------------------------------------------------------------------------------------------------------------------------------------------------------

    [parker@wolfcola cli]$ uname -a
    Linux wolfcola 5.6.12-arch1-1 #1 SMP PREEMPT Sun, 10 May 2020 10:43:42 +0000 x86_64 GNU/Linux
    [parker@wolfcola cli]$ ./buildresults/Linux_x86_64/gcc/flirc_util/release/flirc_util settings
    flirc_util version 26e271e49325ec7e449a705e4d438c7d0426fd0d [26e271e]
    Firmware Detected
    FW Version: v4.6.2v4.6.2
       SKU:     Flirc 2.0 [dori]
       Branch:  master
       Config:  release
       Hash:    0x83E88D26

    Settings:
     sleep detection:  always enabled
     noise canceler:   always enabled
     inter-key delay:  N/A for current firmware
     variant:          Flirc
     builtin profiles: NA
     Memory Info:      NA
     product sku:      Flirc 2.0 [dori]

    Recorded Keys:
    Index  hash       IK   ID  key
    -----  --------   ---  --  ------------
       0  BAE960C9   052  01  up
    [parker@wolfcola cli]$ ./buildresults/Linux_x86_64/gcc/flirc_util/release/flirc_util unit_test
    [E] lib/libflirc/firmware/fw_4.0.c fl_ver4_set_interrupt(367): timeout
    [E] lib/libflirc/firmware/fw_4.2.c _fl_unit_test(132): error recording test0
    Flirc Not Okay

    ------------------------------------------------------------------------------------------------------------------------------------------------------------

     

    And when I try on the Raspberry Pi

    ------------------------------------------------------------------------------------------------------------------------------------------------------------

    [parker@alarmpi cli]$ sudo ./buildresults/Linux_armv7l/gcc/flirc_util/release/flirc_util settings
    flirc_util version 26e271e49325ec7e449a705e4d438c7d0426fd0d [26e271e]
    Firmware Detected
    FW Version: v4.6.2v4.6.2
    [E] lib/libtransport/hid.c hid_recv_packet(161): Wrong response length = 0
    [E] lib/libtransport/hid.c hid_recv_packet(162): hidapi: (null)
    [E] lib/libtransport/transport.c _recv_packet(126): _recv_packet: recv packet error = -1
    [E] lib/libtransport/transport.c _dev_send_cmd(201): recv timeout
    [E] lib/libflirc/firmware/fw_4.0.c fl_ver4_header_peek(50): invalid address you idiot
    [E] lib/libtransport/hid.c hid_recv_packet(161): Wrong response length = 0
    [E] lib/libtransport/hid.c hid_recv_packet(162): hidapi: (null)
    [E] lib/libtransport/transport.c _recv_packet(126): _recv_packet: recv packet error = -1
    [E] lib/libtransport/transport.c _dev_send_cmd(201): recv timeout
    [E] lib/libflirc/firmware/fw_4.0.c fl_ver4_header_peek(50): invalid address you idiot
    [E] lib/libtransport/hid.c hid_recv_packet(161): Wrong response length = 0
    [E] lib/libtransport/hid.c hid_recv_packet(162): hidapi: (null)
    [E] lib/libtransport/transport.c _recv_packet(126): _recv_packet: recv packet error = -1
    [E] lib/libtransport/transport.c _dev_send_cmd(201): recv timeout
    [E] lib/libflirc/firmware/fw_4.0.c fl_ver4_header_peek(50): invalid address you idiot


    ------------------------------------------------------------------------------------------------------------------------------------------------------------

     

    When I try the official packaged flirc_util for armv7 (I had to install libreadline6). No keys and inconsistently running.

    ------------------------------------------------------------------------------------------------------------------------------------------------------------

    [parker@alarmpi Flirc]$ sudo ./flirc_util settings
    3.25.3
    FW Version: v4.6.2v4.6.2
      SKU:     Flirc 2.0 [dori]
      Branch:  master
      Config:  release
      Hash:    0x83E88D26

    Settings:
     sleep detection:  always enabled
     noise canceler:   always enabled
     inter-key delay:  N/A for current firmware
     variant:          Flirc
     builtin profiles: NA
     Memory Info:      NA
     product sku:      Flirc 2.0 [dori]

    Recorded Keys:
    Index  hash       IK   ID  key
    -----  --------   ---  --  ------------
    [parker@alarmpi Flirc]$ sudo ./flirc_util settings
    3.25.3
    FW Version: v4.6.2v4.6.2
    [E] lib/libtransport/hid.c hid_recv_packet(161): Wrong response length = 0
    [E] lib/libtransport/hid.c hid_recv_packet(162): hidapi: (null)
    [E] lib/libtransport/transport.c _recv_packet(126): _recv_packet: recv packet error = -1
    [E] lib/libtransport/transport.c _dev_send_cmd(201): recv timeout
    [E] lib/libflirc/firmware/fw_4.0.c fl_ver4_header_peek(50): invalid address you idiot
    ^C
    Cleaning up....
    [parker@alarmpi Flirc]$ sudo ./flirc_util unit_test
    [E] lib/libflirc/firmware/fw_4.0.c fl_ver4_set_interrupt(367): timeout
    [E] lib/libflirc/firmware/fw_4.2.c _fl_unit_test(132): error recording test0
    Flirc Not Okay

    ------------------------------------------------------------------------------------------------------------------------------------------------------------

     

    EDIT: hidapi version on both machines is hidapi 0.9.0-1
     

    There is a bug in the upstream kernel. Do your pairing on another machine. I don’t have time to debug the kernel. The Kernel is dropping USB packets. I’ve got a ton of debug logs that show it on the wire ,and the kernel stack never gets it.

    The remedy is to slow down communication to the USB device. It’s possible to just push an update (which will have to be done on another machine), and the USB poll time increases and slows it down to fix it. But It slows it down considerably.

    If you use the blue port on the pi, it has a phy in front of it, and doesn’t help mitigate it completely, but helps a lot.

×
×
  • Create New...