Re: 35022: hid-magicmouse broken

[Chase Douglas <chase.douglas@canonical.com>]

On 05/19/2011 07:59 AM, Jiri Kosina wrote:
> On Tue, 17 May 2011, Chase Douglas wrote:
> 
>>>> It seems hid_output_raw_report() is returning a different (incorrect?)
>>>> value than in the past. Do you know what might be going on?
>>>
>>> So we are getting EIO from the transport-level _raw callback.
>>>
>>> Hmm, commit 0825411ade seems like a suspect here. Might be possible that 
>>> magicmouse doesn't send ACK back, right?
>>>
>>> Could you please try reverting that commit and re-test?
>>
>> Yes, reverting that commit makes it work.
>>
>> I'm just speculating here, based on commit message names and what you've
>> said, that the magicmouse is not protocol compliant because it is not
>> sending an ACK back? 
> 
> Yes, I believe that's what is happening. Could you please report what is 
> the dmesg output with the patch below, just to make sure that we 
> understand the situation precisely?

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

>> What do you think we should do in the driver? Should we ignore the 
>> return, or should we look specifically for EIO? (neither sounds very 
>> good to me, so I'm hoping you have a better solution :).
> 
> Well if the device indeed doesn't send the ACK and it should (I will have 
> to check the specs first), we'll have to put a quirk into the driver. 
> Otherwise if the ACK is not mandatory, we'll have to revert that commit 
> (or at least make it non-fatal failure).
> 
> But I'll have to check the specs first.

Sounds good to me :).

Thanks!

-- Chase
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html