Jump to content
Flirc Forums

jason

Administrators
  • Content Count

    2,644
  • Joined

  • Last visited

  • Days Won

    115

jason last won the day on July 2

jason had the most liked content!

Community Reputation

167 Excellent

About jason

  • Rank
    Administrator

Profile Information

  • Gender
    Male
  • Location
    Santa Clara
  • Interests
    flirc, that's all I have time for.

Recent Profile Visitors

15,093 profile views
  1. 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. Nothing I can do about two. You need to learn without your phone present, and then it should work fine. Can you confirm?
  3. 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?
  4. Go to File->Device Logging. Enable device logging. Let's see what kind of noise it's picking up.
  5. 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.
  6. 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
  7. 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.
  8. On my GUI, go to controllers->media keys. There is a suspend key there. Try that, and let us know.
  9. 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.
  10. Yeah, I'm back on development, will get a release out in 2 weeks.
  11. 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.
  12. 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.
×
×
  • Create New...