On Thu, Mar 18, 2010 at 10:03 PM, Wayne Thomas <waynethomas69@xxxxxxxxx> wrote:
> On Thu, Mar 18, 2010 at 12:00 PM, Jiri Kosina <jkosina@xxxxxxx> wrote:
>> On Thu, 18 Mar 2010, Jiri Kosina wrote:
>>
>>> > I have compiled kernel 2.6.33.1 with hid_debug set to 2.
>>> > Below is the output of the appropriate device (the remote presents
>>> > itself as two separate event devices) when pressing some of the
>>> > buttons in question.
>>> >
>>> > I have attached the output of
>>> > /sys/kernel/debug/hid/0003:046E:5578.0004/rdesc as a text file since
>>> > it is so long, but here is the output of
>>> > /sys/kernel/debug/hid/0003:046E:5578.0004/events (one report for each
>>> > button pressed).
>>> >
>>> > report (size 7) (numbered)
>>> >
>>> >
>>> >
>>> > report (size 7) (numbered)
>>> >
>>> >
>>> >
>>> > report (size 7) (numbered)
>>> >
>>> >
>>> >
>>>
>>> Hmm, this is very odd output. Do you by any chance have messages such as
>>>
>>> undefined report_id <NUMBER> received
>>>
>>> appearing in your 'dmesg' output when you are pressing the keys?
>>
>> Does applying the patch below give reasonable output in 'events' debugfs
>> file please?
>>
>>
>>
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index 368fbb0..c49aaa2 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -1096,20 +1096,11 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, int i
>> goto nomem;
>> }
>>
>> - snprintf(buf, HID_DEBUG_BUFSIZE - 1,
>> - "\nreport (size %u) (%snumbered)\n", size, report_enum->numbered ? "" : "un");
>> - hid_debug_event(hid, buf);
>> -
>> - report = hid_get_report(report_enum, data);
>> - if (!report) {
>> - kfree(buf);
>> - return -1;
>> - }
>> -
>> /* dump the report */
>> snprintf(buf, HID_DEBUG_BUFSIZE - 1,
>> - "report %d (size %u) = ", report->id, size);
>> + "\nreport (size %u) (%snumbered) = ", size, report_enum->numbered ? "" : "un");
>> hid_debug_event(hid, buf);
>> +
>> for (i = 0; i < size; i++) {
>> snprintf(buf, HID_DEBUG_BUFSIZE - 1,
>> " %02x", data[i]);
>> @@ -1117,6 +1108,13 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, int i
>> }
>> hid_debug_event(hid, "\n");
>>
>> + report = hid_get_report(report_enum, data);
>> +
>> + if (!report) {
>> + kfree(buf);
>> + return -1;
>> + }
>> +
>> kfree(buf);
>>
>> nomem:
>>
>
> Jiri,
> nothing at all appears in dmesg in relation to the button presses.
> I manually applied the patch and have retested. The only difference I
> noticed was the presence of an equals sign in events:
>
> report (size 7) (numbered) =
>
>
> rdesc appears identical, but I have attached it just in case.
>
> Also, in the off-chance that it is any use, here is the output of
> dmesg when I plug the receiver in (there is no output when any buttons
> are pressed).
>
> [ 572.392097] usb 3-1: new low speed USB device using uhci_hcd and address 4
> [ 572.577199] drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 0
> [ 572.590688] input: BTC USB MCE Cordless Remote Control. as
> /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/input/input12
> [ 572.590843] generic-usb 0003:046E:5578.0005: input,hidraw0: USB HID
> v1.11 Keyboard [BTC USB MCE Cordless Remote Control.] on
> usb-0000:00:1d.1-1/input0
> [ 572.590969] drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 1
> [ 572.611848] drivers/hid/usbhid/hid-core.c: submitting ctrl urb:
> Get_Report wValue=0x0101 wIndex=0x0001 wLength=2
> [ 572.614082] drivers/hid/usbhid/hid-core.c: submitting ctrl urb:
> Get_Report wValue=0x0102 wIndex=0x0001 wLength=7
> [ 572.617082] drivers/hid/usbhid/hid-core.c: submitting ctrl urb:
> Get_Report wValue=0x0103 wIndex=0x0001 wLength=7
> [ 572.621086] drivers/hid/hid-core.c: undefined report_id 0 received
> [ 572.621095] drivers/hid/usbhid/hid-core.c: submitting ctrl urb:
> Get_Report wValue=0x0303 wIndex=0x0001 wLength=8
> [ 572.625084] drivers/hid/hid-core.c: undefined report_id 0 received
> [ 572.625366] input: BTC USB MCE Cordless Remote Control. as
> /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.1/input/input13
> [ 572.625576] generic-usb 0003:046E:5578.0006:
> input,hiddev96,hidraw1: USB HID v1.11 Device [BTC USB MCE Cordless
> Remote Control.] on usb-0000:00:1d.1-1/input1
>
> Cheers
> Wayne
>
Jiri,
I haven't heard anything for quite a while so assume that you have
more pressing priorities than this.
In the meantime it occured to me that it would be relatively simple
for me to patch hid-topseed to support this item (the keymaps are
identical apart from a few extra keys).
If I created this patch would it be accepted as an interim support
solution until the udev method actually works? I figure hid-topseed
is already in existence so it wouldn't be adding additional quirky
drivers and once the ffbc usage page works under udev there is no
extra effort to migrate to this method.
Thoughts?
Cheers
Wayne
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
