Jump to content
Flirc Forums

jason

Administrators
  • Content Count

    2,646
  • Joined

  • Last visited

  • Days Won

    115

Everything posted by jason

  1. don't use an extension chord, it might be the extension chord more than the phone.
  2. God logitech sucks. Hang in there, I think something might be coming soon to put them to fucking shame... But for now, remove all this from logitech. Add a Samsung or Panasonic device to the logitech, rename it flirc. Add whatever device is NOT in your room. In other words, if you have a samsung, don't add the samsung. Now once that's added. Open up my software, go to the NVIDIA controller, and pair each key manually. Then go to advanced, disable all the built in profiles. Don't have roomba on as you're doing any of this. Let me know how that goes.
  3. 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.
  4. Nothing I can do about two. You need to learn without your phone present, and then it should work fine. Can you confirm?
  5. 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?
  6. Go to File->Device Logging. Enable device logging. Let's see what kind of noise it's picking up.
  7. 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.
  8. 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 nemo.release-4.9.4.bin
  9. 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.
  10. On my GUI, go to controllers->media keys. There is a suspend key there. Try that, and let us know.
  11. 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.
  12. Yeah, I'm back on development, will get a release out in 2 weeks.
  13. 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.
  14. 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 Another Reference 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.
  15. 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.
  16. I'd be interested in knowing this too. By the way, who the hell has a PS/2 port on their PC still?
  17. 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.
  18. Make sure the GUI is closed before running the command line.
  19. Make sure the GUI is closed before running the command line.
  20. looks awesome, pair that with the profile, and try it, let me know if that works. If it works, it's the remote
  21. 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?
×
×
  • Create New...