Key stuck with Samsung IR remote (USB 0419:0001)

>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.

BTW, please doublecheck whether usage code 0224 is really contained twice in the report descriptor. This looks very strange.

Also peculiar is that the logical maximum is claimed to be 18, but only 15 usages are provided. Maybe array indices 16..18 are generated, but dropped due to missing usage code.

One of these points might explain why 3 keys are missing.

BTW, do the supported remote keys match exactly with the kernel mapping from the consumer usage page (Vol up/down, etc.)? I was positively surprised that at least for this device variant a proprietary usage page was avoided.

Thanks for the patch, I will try that once I have some time for it. And I hope I can answer at least some of the questions:

> - Precisely, which device was this?

Excellent question, but it is part of a media TV branded "optronix" (but made by amazepc, at least the board), so I am not quite sure. The remote says "optronix", and the chip inside is marked "EM78P447SAM-G", which seems like Samsung. I may be able to disassemble the receiver, and see whether anything is printed on the board or the controller chip. I thought it was Samsung, but I admit this may not be the case.

> - Can you please also please provide "lsusb -v" without connected daemon?

I tried it without X server and without any kernel module, but I get the same result. I think there is a syntactical error in the descriptor, and the kernel seems to be able to work around it (see the kernel log), but lsusb -v just ignores that part.

> please doublecheck whether usage code 0224 is really contained twice in the report descriptor

That is what the kernel says, and it also appears twice in the hex dump.

> do the supported remote keys match exactly with the kernel mapping

No, not quite. I have to check the exact matching, but it seemed to be made for a remote control with different labels: the keys would make sense the way the kernel interprets them, but it is not how the control is labeled.

> One of these points might explain why 3 keys are missing.

Yes, I am still puzzled by these. I have heard reports that Windows has the same problem, but I did not really manage to get it to work, so I cannot confirm that. Is there a way to trace the USB data stream, instead of using the raw hid device?

Sorry this took a while, but the graphics card does not like 2.6.29 - I will have to figure that out at some point.

For the remote, the patch works great. There is only one key not working, the ENTER key, and that may be a problem with the device rather than the driver. Great work!

Is there anything else I can do? I will add a list of key codes and the corresponding keys soon, although that may be specific to this remote rather than the receiver.

>For the remote, the patch works great. There is only one key not working, the ENTER key, and that may be a problem with the device rather than the driver. Great work!
>Is there anything else I can do?

Very well. As said before, each key must be reported via one of the reports from the descriptor. So if there is no raw event (and no trace output with enabled HID debug option) on pressing ENTER, I guess there is nothing to do. But in this case, the prepackaged SW also should be unable to support the ENTER key (sounds strange).

I am currently collecting reports from other 0419:0001 devices, as now there seem to be at least four devices with the same vendor/class id but different report descriptors. After collecting those, I might submit a merged patch to the kernel list. If you get some news on the ENTER key meanwhile, this would be worth to clarify.

This is not a bug in the linux-meta package, moving to the linux package.

Integrated into the HID kernel preintegration branch now:
http://www.spinics.net/lists/linux-input/msg03763.html

I've got a similar device.
Bus 004 Device 002: ID 0419:0001 Samsung Info. Systems America, Inc. IrDA Remote Controller
The wDescriptorLength for it is 171. After patching my kernel with this patch http://launchpadlibrarian.net/25472216/samsung203b-2.6.29.patch the device works fine, except of two keys: Volume Up and Volume Down. When pressing any of these 2 keys, they stuck with the code of Volume Down key (I was investigating it with the showkey command).
Then i applied this patch http://launchpadlibrarian.net/22301251/hid-core.patch This fixed key stuck, but another problem rose: now only the Volume Up key works. Volume down does not at all, at least
# cat /dev/hidraw*
does not show anything when pressing Volume Down.
As I mentioned, the device has a descriptor 171, which is something new (it is not listed in the patch http://launchpadlibrarian.net/25472216/samsung203b-2.6.29.patch, though it works when applying it).
I'm eager to help if any additional info is needed.

>I've got a similar device.
>Bus 004 Device 002: ID 0419:0001 Samsung Info. Systems America, Inc. IrDA Remote Controller
>The wDescriptorLength for it is 171.
Yet another 0419:0001 device. I already read about descriptors with 184, 203, 135, 199 bytes.

>After patching my kernel with this patch http://launchpadlibrarian.net/25472216/samsung203b-2.6.29.patch the device works fine, except of two keys:

This patch only brought back the old state for all 0419:0001 devices without 184b descriptor, i.e.using the regular HID input device. Probably your device still has some minor descriptor quirk, rendering your two keys useless.

>Then i applied this patch http://launchpadlibrarian.net/22301251/hid-core.patch This fixed key stuck, but another problem rose
I do not recommend this workaround anyway.

Please post your output of "lsusb -v" for the remote. If the report descriptor is shown as unavailable, you might need to unload any daemons or even the hid module. Alternatively, load the HID kernel module with the debug option enabled -- similar to the original poster above.

Brand/device info of this remote would be interesting

Probably /dev/hidraw output for vol keys would also be interesting (w/o the workaround patch).

I am attaching the output of lsusb -v for my device.
>If the report descriptor is shown as unavailable
The report descriptors are indeed shown as unavailable, but I am not sure how to proceed with your further instructions.
>you might need to unload any daemons or even the hid module.
What daemons do you mean? What if I have the hid-samsung built in-kernel, not as a module?
>Alternatively, load the HID kernel module with the debug option enabled -- similar to the original poster above.
The same as above: what if I have the hid-samsung built in-kernel, not as a module? I have hid_debug enabled (in-kernel also). How do I dump the debug log?
>Brand/device info of this remote would be interesting
It's a "noname" device. The website is here: http://www.pcpult.com.ua/en_index.html
>Probably /dev/hidraw output for vol keys would also be interesting (w/o the workaround patch).
Not sure if that is what you need, but did a cat /dev/hidraw* and the output in the console while pressing the volume keys was just a mess like this: ^@^@^@^@^@^@^@^@^@

>What daemons do you mean? What if I have the hid-samsung built in-kernel, not as a module?

You need to have the usbhid driver disabled (and any daemons on top like Lirc). If usbhid is a module, unload it via "modprobe -r usbhid". If built in, compile kernel without it or as module.

>The same as above: what if I have the hid-samsung built in-kernel, not as a module? I have hid_debug enabled (in-kernel also). How do I dump the debug log?

"hid_debug=1" is a module option on module "hid". If it is enabled and you plug in the device (or during startup), you should see a report similar to "kernlog.gz" from the original poster. It shows the key mappings from parsing the report descriptor and a descriptor hexdump.

>It's a "noname" device. The website is here: http://www.pcpult.com.ua/en_index.html

Funnily, this site claims that it works under Linux. Might have been before 2.6.25, when support for the 184 byte variant disabled the HID input mapping which is essential for your variant. Abovementioned patch resolves this for all variants. But even then those 2 vol keys should not have worked before, as they seem to need a separate quirk entry.

>Not sure if that is what you need, but did a cat /dev/hidraw* and the output in the console while pressing the volume keys was just a mess like this
Binary. Try something like "hexdump /dev/hidraw" and note down which key event (press / release) triggered which hex bytes. Again, similar to what the original poster attached.

@ticket admin: I am unsure whether tracking belongs into this or a new ticket. Original issue to be solved with patch in upcoming Linux 2.6.32. If other variants come up, we might never get this closed.

OK, I managed to gather all the logs you suggested (or at least I think so).
The first is the dmesg output upon plugging in the device. See the dmesg attachment, it describes all the steps I took.
The second is the lsusb -v output. This output was got with hid, usbhid and hid_samsung modules _unloaded_
And the last is cat /dev/hidraw1 upon pressing the volume keys (hidraw attachment). The problem here is that every other key on the remote, when pressed, except the volume ones, results in two lines of code in console on cat /dev/hidraw1 (from what I understand, the first line is key press code, the second is key release code). The volume keys result only one line of code (the press code only), that is why they stuck. So, the hidraw attachment shows two codes: the first is vol down key press, the second is vol up key press. The freaky symbols '^@' are produced because the keys are actually stuck.
Please let me know if anything else is needed.

>Please let me know if anything else is needed.
OK, just checked your attachments.

The volume keys are used from the consumer page.This array range looks suspicious to me:
  Item(Global): Logical Minimum, data= [ 0x00 ] 0
  Item(Global): Logical Maximum, data= [ 0x01 ] 1

I would rather try to patch this to a range of 1..3. However, your kern log did not include the upper part with the descriptor as hex bytes, so I cannot easily guess patch positions. See the original poster who included some part starting with "report descriptor (size ..., read ...) = .....". Should also be shown when debug option is enabled.

Either you clipped this section off, or you used a brand-new 2.6.32rc kernel which exports this via debugfs only (to my knowledge, never tried). Can you please try to provide the hex dump? In drivers/hid/usbhid/hid-core.c from 2.6.29 the trace looked like
  dbg_hid("report descriptor (size %u, read %d) = ", rsize, n);...

>The volume keys result only one line of code (the press code only), that is why they stuck.
To me it seems like the press already triggers the release event too (value 0), so it might only look like a single event. Value 0/off is ignored because it is in the value range. But difficult to say w/o device.

I am attaching the full dmesg output. For some reason, it does not output all the data upon initial plugging in the device, but if you then plug it out and plug in again - you'll get the whole picture including report descriptor (size 171, read 1) = ...
So, I believe the attached is what you asked for.
By the way, "kernel log: HID descriptor" attachment from initial poster is not readable for me, even unpacked. How can it be read and how to create such a dump?

>I am attaching the full dmesg output. For some reason, it does not output all the data upon initial plugging in the device, but if you then plug it out and plug in again - you'll get the whole picture including report descriptor (size 171, read 1) = ...

Please test the attached patch. It is on top of the previous patch samsung-203b-2.6.29.patch. Kernel base was 2.6.31, but should not matter that much.

Of course, untested by me, w/o such device.

>By the way, "kernel log: HID descriptor" attachment from initial poster is not readable for me, even unpacked. How can it be read and how to create such a dump?
Simple gzip'ed text file.

Thanks a lot! Works perfectly with kernel 2.6.31.

rs, did you send back your patches to the lkml?

From what I can see, patches for all the devices, discussed here (except of 171 one), are in 2.6.32 release. I hope to see the 171 device (which is actually the one I have) in the later releases.

Sounds good, we could help to push the patch to the upstream kernel, if the author needs our help.
Besides, we could also cherry-pick the patch from upstream kernel to the karmic kernel, so that you can have the fix on karmic.

The hash value of the 203b patch in the upstream kernel is 0810b51170570ed21cae56b8131db6a5e3efa584
I'll try to issue a SRU for our karmic kernel to adapt that patch.

And for the 171b patch, Robert(rs), will you sent the patch to the upstream kernel, or do you need me to send the patch?

>And for the 171b patch, Robert(rs), will you sent the patch to the upstream kernel, or do you need me to send the patch?

I will baseline the "171 byte quirk fix" to the new 2.6.32 kernel and submit to the kernel list soon.

Unsure, whether you want to split this tracking off into a new ticket, because the original poster had a different device/issue. Hopefully, this ticket gets closed before any new quirk devices are found and attached to this ticket.

Refactored 171b patch was applied upstream in the HID preintegration branch:
http://www.spinics.net/lists/linux-input/msg06276.html

Robert, good jobs, ubuntu kernel will have your fix after rebasing with upstream kernel.