On Thu, 19 May 2011, Chase Douglas wrote:
> Here's the output in dmesg:
>
> [ 195.491735] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
> [ 222.693947] input: cndougla’s trackpad as
> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/bluetooth/hci0/hci0:12/input16
> [ 222.694119] magicmouse 0005:05AC:030E.0005: input,hidraw3: BLUETOOTH
> HID v1.60 Mouse [cndougla’s trackpad] on 50:63:13:90:AF:A4
> [ 222.694128] hidp_output_raw_report, report_type: 2
> [ 222.808111] session ffff88012d9b1200 param 0x02
> [ 222.808198] hidp: returnign -EIO because of !output_report_success
> [ 222.808209] magicmouse 0005:05AC:030E.0005: unable to request touch
> data (-5)
> [ 222.809358] session ffff88012d9b1200 param 0x02
> [ 222.810606] session ffff88012d9b1200 param 0x02
> [ 222.813113] session ffff88012d9b1200 param 0x00
> [ 223.045363] magicmouse: probe of 0005:05AC:030E.0005 failed with error -5
Ok, so what is happening here is that magicmouse_probe() sends the { 0xd7,
0x01 } feature report to the device, and it responds with
HIDP_HSHK_ERR_INVALID_REPORT_ID.
That's why the _raw callback (correctly) returns error.
So the question to the driver authors is -- what is the point behind the {
0xd7, 0x01 } report? Clearly the device doesn't like it during probe
because of invalid report ID.
And it never did, we just silently ignored the error with the older
kernels.
Michael?
--
Jiri Kosina
SUSE Labs
--
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
