On 05/19/2011 12:03 PM, Jiri Kosina wrote:
> On Thu, 19 May 2011, Chase Douglas wrote:
>
>>>> [ 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?
>
> Hmm, I am afraid that it's the only option (apart from thowing the whole
> 'waiting for ack' infrastructure away, which would be sad, as it's a good
> thing in principle).
>
> So how about the patch below? :/ Could you please verify that it makes
> hid-magicmouse work again? Thanks.
>
>
>
> From: Jiri Kosina <jkosina@xxxxxxx>
> Subject: [PATCH] HID: magicmouse: ignore 'ivalid report id' while switching modes
>
> The device reponds with 'invalid report id' when feature report switching it
> into multitouch mode is sent to it.
>
> This has been silently ignored before 0825411ade ("HID: bt: Wait for ACK
> on Sent Reports"), but since this commit, it propagates -EIO from the _raw
> callback .
>
> So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's
> how the device reacts in normal mode.
>
> Sad, but following reality.
>
> This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022
>
> Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
> ---
> drivers/hid/hid-magicmouse.c | 10 +++++++++-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> index 0ec91c1..a5eda4c 100644
> --- a/drivers/hid/hid-magicmouse.c
> +++ b/drivers/hid/hid-magicmouse.c
> @@ -501,9 +501,17 @@ static int magicmouse_probe(struct hid_device *hdev,
> }
> report->size = 6;
>
> + /*
> + * The device reponds with 'invalid report id' when feature
> + * report switching it into multitouch mode is sent to it.
> + *
> + * This results in -EIO from the _raw low-level transport callback,
> + * but there seems to be no other way of switching the mode.
> + * Thus the super-ugly hacky success check below.
> + */
> ret = hdev->hid_output_raw_report(hdev, feature, sizeof(feature),
> HID_FEATURE_REPORT);
> - if (ret != sizeof(feature)) {
> + if (ret != -EIO) {
> hid_err(hdev, "unable to request touch data (%d)\n", ret);
> goto err_stop_hw;
> }
Seems to work for me :).
Reviewed-by: Chase Douglas <chase.douglas@xxxxxxxxxxxxx>
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
