>I have a Samsung IR remote that should work as a USB HID device. I need to do some tweaking with modprobe options in /etc/modprobe.d/options to get it recognised (see options), and then it mostly works.
OK, so you already performed some good preanalysis. Your quirk option 0x10 reenables the input path again (which is disabled by the quirk for the other 0419:0001 device). FYI, this would probably not work anymore with 2.6.28ff which restructured the quirk handling (less bit options to influence handling externally, however more flexible architecture internally). >For one key press, the trace from the device looks normal (see rawhid.dump), but the "sanitized" version (see hiddev-before.dump) shows a key press event for e9 at the end. I am no expert of the HID spec, but it seems that the device uses a seriously broken definition. I turned on HID debugging to get this definition (see kern.log.gz). Field 4 has an offset of 0, so the first key becomes indistinguishable from no key press - and the kernel gets confused by this. The raw dump would be most interesting, and also when you pressed which key. However, I think to understand the basic issue. The logical minimum in fact is 0 in the report descriptor, while the HID standard recommends minimum 1 and maximum equal to the number of entries, to filter out empty entries. >Now I am not sure that this is a best fix, or that it has no side effect, but it works for me. Maybe it would be better to raise the minimum? The patch certainly affects all HID devices, so it is only a workaround for you. I have attached a patch against 2.6.29 which should recognize and handle your device using the new descriptor size -- of course untested, without such device in front of me. Later, I might add the bcdDevice which also seems to differ between both. >And even with this fix, there are three buttons that I cannot get to works. But I have been tracing the USB connection, and I cannot figure out how they could possibly work, so I will leave that for now. The buttons can only be reported with the reports signalled by the descriptor. If you also checked on low level with HID debug traces and monitored hidraw without apparent reaction, I guess that the buttons should also be nonfunctional in the delivered application. Did you try it there? >Maybe Samsung tried to fix the earlier issues, but they introduced a new one. Of course it is a shame that the USB ID is still the same. Unclear whether it is Samsung or actually another vendor to blame for rebranding. But you are right, keeping vendor/class id with such changes is ugly. Some questions: - Precisely, which device was this? - Can you please also please provide "lsusb -v" without connected daemon? Currently, the report descriptor is shown as unavailable due to a client. Of course, most of the parse tree is visible in kernlog, but to doublecheck this would be nice. ** Attachment added: "Patch for 0419:0001 203 byte device against 2.6.29" http://launchpadlibrarian.net/25472216/samsung203b-2.6.29.patch -- Key stuck with Samsung IR remote (USB 0419:0001) https://bugs.launchpad.net/bugs/326986 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
