Thread (12 messages) 12 messages, 2 authors, 2011-05-23

Re: 35022: hid-magicmouse broken

From: Chase Douglas <hidden>
Date: 2011-05-19 13:13:11

On 05/19/2011 07:59 AM, Jiri Kosina wrote:
On Tue, 17 May 2011, Chase Douglas wrote:
quoted
quoted
quoted
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
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help