jason
-
Posts
2,744 -
Joined
-
Last visited
-
Days Won
118
Posts posted by jason
-
-
Nothing I can do about two. You need to learn without your phone present, and then it should work fine. Can you confirm?
-
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?
-
Go to File->Device Logging. Enable device logging. Let's see what kind of noise it's picking up.
-
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: 0xA41ECA3AThe 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.
-
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.
-
1
-
-
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.
-
On my GUI, go to controllers->media keys. There is a suspend key there.
Try that, and let us know. -
You'll want to add Device: Flirc
Model: Shield
Clear your configuration on the device. The configuration is built in. Let me know if that helps.
-
On your harmony, what device are you using?
-
Can you post your config?
-
Can you post your config?
-
Yeah, I'm back on development, will get a release out in 2 weeks.
-
I don't know what the hell is wrong with windows. I'm sorry. There are no viruses. It's crazy. It doesn't say what it is, it's erroneous.
-
1
-
-
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
QuoteLooks 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.
QuoteNote: 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.
-
It's done, packaging is done, I just have to pull the trigger. But the pandemic has been killing me. Every day, I'm slammed. I'm going to try and kick it off this week.
-
1
-
-
On 4/2/2020 at 4:13 PM, Zapto said:
Are you shipping? I placed an order yesterday, wondering if I should cancel it.
Every day
-
I'd be interested in knowing this too. By the way, who the hell has a PS/2 port on their PC still?
-
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. -
Make sure the GUI is closed before running the command line.
-
Make sure the GUI is closed before running the command line.
-
looks awesome, pair that with the profile, and try it, let me know if that works. If it works, it's the remote
-
something is not right, it's sending inconsistent signals. Is it low on batteries? You have any remote handy that you can try to see if we can narrow this down?
-
Can you also post your config file? Can you do this again, don't hold your remote too close to flirc, in fact, point up towards the ceiling. Not seeing good results in the above.
-
Open up my app on your PC, go to File->Device Log.
Enable IR debugging. And press and hold the button in question. Post the log here.
Does configuration file get applied to the FLIRC usb device, the machine, or both?
in General Questions
Posted
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.