[Bug 326986] Re: Key stuck with Samsung IR remote (USB 0419:0001)

rs r.schedel at yahoo.de
Tue Apr 14 22:20:21 UTC 2009


>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 Kernel
Bugs, which is subscribed to linux-meta in ubuntu.




More information about the kernel-bugs mailing list