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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html