On 05/19/2011 10:54 AM, Jiri Kosina wrote:
> 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.
The feature report is what flips the devices (magic mouse, magic
trackpad) into multitouch mode. Without the report, the mouse will not
emit the location of any touches on its surface, and the trackpad will
only emit single touch data.
What do you think we should do? We can't get rid of the report. Should
we silently ignore the error?
Thanks
--
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
