Comment 11 for bug 326986

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?