Magic trackpad issues on 3.0

5 messages, 3 authors, 2011-08-16 · open the first message on its own page

Magic trackpad issues on 3.0

From: Jaikumar Ganesh <hidden>
Date: 2011-08-15 20:18:49

Folks,
   This is with regard to the issue:

http://www.spinics.net/lists/linux-input/msg15334.html

As mentioned in that thread we were ignoring the EIO return value earlier.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3a4924565e2eecf2539871abd123d35be6d76d5

reverted the commit back, because

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7f4f0572df6c8eaa6a587bc212b0806ff37380dd
fixed the issue with the Bluetooth stack with 1.1 Bluetooth devices.

However, I am seeing the same problem with an Apple Trackpad which is
2.0 Bluetooth device. It worked fine before because we were ignoring
the EIO.

The Error code is the same as mentioned in the thread above: Invalid
Report ID while calling the Set Feature Report call.

So to the driver authors:

In magicmouse_probe function, the report id is set to d7. __u8
feature[] = { 0xd7, 0x01 };

Is it guaranteed that all Apple devices will have 0xd7 as the report
Id. Why are we not reading the report ID from the report descriptor
since its an optional feature ?

I am going to sniff the traffic to check if the report ID for this
device is different.

Is anyone else aware of the issue ?

Thanks

Re: Magic trackpad issues on 3.0

From: Michael Poole <hidden>
Date: 2011-08-16 02:04:06

On Mon, Aug 15, 2011 at 4:18 PM, Jaikumar Ganesh wrote:
Folks,
  This is with regard to the issue:

http://www.spinics.net/lists/linux-input/msg15334.html

As mentioned in that thread we were ignoring the EIO return value earlier.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3a4924565e2eecf2539871abd123d35be6d76d5

reverted the commit back, because

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7f4f0572df6c8eaa6a587bc212b0806ff37380dd
fixed the issue with the Bluetooth stack with 1.1 Bluetooth devices.

However, I am seeing the same problem with an Apple Trackpad which is
2.0 Bluetooth device. It worked fine before because we were ignoring
the EIO.

The Error code is the same as mentioned in the thread above: Invalid
Report ID while calling the Set Feature Report call.

So to the driver authors:

In magicmouse_probe function, the report id is set to d7. __u8
feature[] = { 0xd7, 0x01 };

Is it guaranteed that all Apple devices will have 0xd7 as the report
Id. Why are we not reading the report ID from the report descriptor
since its an optional feature ?
The report descriptor does not include that feature report.  There are
a number of commands for Apple's Magic Mouse and Magic Trackpad that
are not listed in the standard HID descriptor.

Michael Poole
--
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

Re: Magic trackpad issues on 3.0

From: Jaikumar Ganesh <hidden>
Date: 2011-08-16 02:40:45

Hi Michael:

On Mon, Aug 15, 2011 at 7:03 PM, Michael Poole [off-list ref] wrote:
On Mon, Aug 15, 2011 at 4:18 PM, Jaikumar Ganesh wrote:
quoted
Folks,
  This is with regard to the issue:

http://www.spinics.net/lists/linux-input/msg15334.html

As mentioned in that thread we were ignoring the EIO return value earlier.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3a4924565e2eecf2539871abd123d35be6d76d5

reverted the commit back, because

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7f4f0572df6c8eaa6a587bc212b0806ff37380dd
fixed the issue with the Bluetooth stack with 1.1 Bluetooth devices.

However, I am seeing the same problem with an Apple Trackpad which is
2.0 Bluetooth device. It worked fine before because we were ignoring
the EIO.

The Error code is the same as mentioned in the thread above: Invalid
Report ID while calling the Set Feature Report call.

So to the driver authors:

In magicmouse_probe function, the report id is set to d7. __u8
feature[] = { 0xd7, 0x01 };

Is it guaranteed that all Apple devices will have 0xd7 as the report
Id. Why are we not reading the report ID from the report descriptor
since its an optional feature ?
The report descriptor does not include that feature report.  There are
a number of commands for Apple's Magic Mouse and Magic Trackpad that
are not listed in the standard HID descriptor.
Has Apple documented this anywhere ? Will every Apple trackpad support it ?
Should we continue to have some fail-safe like the EIO fix ?
Michael Poole
--
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

Re: Magic trackpad issues on 3.0

From: Michael Poole <hidden>
Date: 2011-08-16 03:45:27

On Mon, Aug 15, 2011 at 10:40 PM, Jaikumar Ganesh wrote:
Hi Michael:

On Mon, Aug 15, 2011 at 7:03 PM, Michael Poole [off-list ref] wrote:
quoted
On Mon, Aug 15, 2011 at 4:18 PM, Jaikumar Ganesh wrote:
quoted
Folks,
  This is with regard to the issue:

http://www.spinics.net/lists/linux-input/msg15334.html

As mentioned in that thread we were ignoring the EIO return value earlier.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3a4924565e2eecf2539871abd123d35be6d76d5

reverted the commit back, because

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7f4f0572df6c8eaa6a587bc212b0806ff37380dd
fixed the issue with the Bluetooth stack with 1.1 Bluetooth devices.

However, I am seeing the same problem with an Apple Trackpad which is
2.0 Bluetooth device. It worked fine before because we were ignoring
the EIO.

The Error code is the same as mentioned in the thread above: Invalid
Report ID while calling the Set Feature Report call.

So to the driver authors:

In magicmouse_probe function, the report id is set to d7. __u8
feature[] = { 0xd7, 0x01 };

Is it guaranteed that all Apple devices will have 0xd7 as the report
Id. Why are we not reading the report ID from the report descriptor
since its an optional feature ?
The report descriptor does not include that feature report.  There are
a number of commands for Apple's Magic Mouse and Magic Trackpad that
are not listed in the standard HID descriptor.
Has Apple documented this anywhere ? Will every Apple trackpad support it ?
Should we continue to have some fail-safe like the EIO fix ?
Hi Jaikumar,

I do not believe Apple has documented the protocol anywhere, or makes
any guarantee of compatibility in future devices -- although forward
compatibility makes sense in terms of the installed base of drivers,
and I suspect any devices that use a different protocol would get
different device IDs.

I think the EIO fix should stay.

Michael Poole
--
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

Re: Magic trackpad issues on 3.0

From: Chase Douglas <hidden>
Date: 2011-08-16 18:48:36

On 08/15/2011 08:45 PM, Michael Poole wrote:
On Mon, Aug 15, 2011 at 10:40 PM, Jaikumar Ganesh wrote:
quoted
Hi Michael:

On Mon, Aug 15, 2011 at 7:03 PM, Michael Poole [off-list ref] wrote:
quoted
On Mon, Aug 15, 2011 at 4:18 PM, Jaikumar Ganesh wrote:
quoted
Folks,
  This is with regard to the issue:

http://www.spinics.net/lists/linux-input/msg15334.html

As mentioned in that thread we were ignoring the EIO return value earlier.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c3a4924565e2eecf2539871abd123d35be6d76d5

reverted the commit back, because

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=7f4f0572df6c8eaa6a587bc212b0806ff37380dd
fixed the issue with the Bluetooth stack with 1.1 Bluetooth devices.

However, I am seeing the same problem with an Apple Trackpad which is
2.0 Bluetooth device. It worked fine before because we were ignoring
the EIO.

The Error code is the same as mentioned in the thread above: Invalid
Report ID while calling the Set Feature Report call.

So to the driver authors:

In magicmouse_probe function, the report id is set to d7. __u8
feature[] = { 0xd7, 0x01 };

Is it guaranteed that all Apple devices will have 0xd7 as the report
Id. Why are we not reading the report ID from the report descriptor
since its an optional feature ?
The report descriptor does not include that feature report.  There are
a number of commands for Apple's Magic Mouse and Magic Trackpad that
are not listed in the standard HID descriptor.
Has Apple documented this anywhere ? Will every Apple trackpad support it ?
Should we continue to have some fail-safe like the EIO fix ?
Hi Jaikumar,

I do not believe Apple has documented the protocol anywhere, or makes
any guarantee of compatibility in future devices -- although forward
compatibility makes sense in terms of the installed base of drivers,
and I suspect any devices that use a different protocol would get
different device IDs.

I think the EIO fix should stay.
I just started to notice this issue last week. The Ubuntu 3.0.0-7 kernel
(the -# part is an ubuntu suffix) seems to work fine, but 3.0.0-8 does
not. I would guess a -stable patch is causing a regression, but the diff
stat from 3.0 to 3.0.1 doesn't show anything related to input, hid, or
bluetooth.

-- Chase
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help