Bug 60181

Created attachment 106161 [details]
xinput list, Xorg logs from 2013 Macbook Air 13"

xinput list, Xorg log excerpts from 2013 Macbook Air 13" trying with mtrack driver and different varieties of the synaptics driver.

I also have a 2013 MBA - here are some logs that hopefully might be helpful.

I am afraid we will need some module/kernel hackery to extract more information.

1) There is a long-standing conflict between the core input drivers (bcm5974 here) and the hid driver (hid-generic here), so to make sure the error (-32) is not related this, please unbind the device completely from the usbhid driver (echo the device id to /sys/bus/usb/drivers/usbhid/unbind).

2) Patch to do the above in the hid core attached, here assuming you have the MacBookAir5,2 ISO model (and that the other models will appear as 0292 and 0293).

3) Patch to attempt add the device to bcm5974 also attached. This may not be enough, as already hinted, but it will give us the possibility to run debug and eventually make things work.

4) Unrelated, but the keyboard also often needs tweaking, which would result in a patch to hid-apple.c.

Covering as much as possible of the above, testing wise, would be great.

Thanks,
Henrik

Created attachment 106251 [details]
hid patch to mask the new device

Created attachment 106261 [details]
bcm5974 patch to add support for the new device

Henrik,

I'll give the patch a shot.

As you mentioned some steps that I have already attempted, I'll fill you in on what I have tried.

In prior testing, I have directly unbind the device from the usbhid, removed the device-id from the usbhid (remove_id), added the device-id to the bcm5974 (new_id) and then bind the device to the bcm5974 (all via the sysfs).  That is how I was able to get the 'could not read from device' error in dmesg.

I have also attempted what amounts to the same bcm5974 patch as you provided (to add the new device ids 0291, 0292, 0293); it had yielded the same results after unbinding the device from usbhid and binding it to bcm5974.

I have not, however, tried to patch the hid, so that may yield different results.

Also, the 0291 touchpad endpoint seems to be 83 rather than 84 (/sys/bus/usb/devices/1-5:1.2/ep_83). Probably unrelated, there are now three interfaces for the device 1-5:1.0 'Device Management', 1-5:1.1 'Keyboard / Boot', and 1-5:1.2 'Trackpad / Boot' (as reported in /sys/bus/usb/devices/1-5:1.?/interface) -- this seems to be slightly different than the prior hardware.

For now, I am not seeing any keyboard issues on the new hardware.

Thanks, I'll give it all another try.  Let me know if there are specific logs that you would like to see as a result.

Just a side-note -- the new MBA mid2013 are 6,2 rather than 5,2.

- Brad

Henrik,

I applied the two patches to the 3.9.8 kernel (I was not able to get 3.9.10-rc7 to boot the MBA-2013 laptop).

The result is both a nonfunctional touchpad (completely) as well as a nonfunctional keyboard (I'm guessing you kind of expected that one). I had to use a USB mouse and keyboard.

dmesg gives the two errors (repeated twice):
bcm5974 1-5:1.2: could not read from device
bcm5974: mode switch failed 

I will attach a series of log files that I took in attempt to provide a decent amount of information.

I also took the same log files on a MacBook Air mid2012 model for comparison if it is of interest.  One thing that stood out to me was that the 2012 has three interfaces 'Apple Internal Keyboard, Touchpad, Touchpad' with the endpoints 83,81,84 vs the 2013 that has the three interfaces 'Device Management, Keyboard / Boot, Trackpad / Boot' with the endpoints 81,82,83.

Let me know if I can provide anything else to help.

- Brad

Created attachment 106281 [details]
Various logs from MBA-mid2013

Series of logs captured from a MBA-mid2013 running a 3.9.8 kernel with the provided patches applied (bcm5974 and hid).

Created attachment 106291 [details]
Comparison logs from MBA-mid2012

Same series of logs captured from a MBA-mid2012 running the same 3.9.8 kernel with the provided patches applied (bcm5974 and hid).

This is just for comparison to the attached mba-2013 set of logs.

Brad,

thanks for the logs. So the interface is indeed different, and the message size is different too, so we expect new information to be in there. Since this is a HID device, and Apple has become more HID friendly over the years, we might be able to get a good grip by extracting the full HID reports, as per http://lii-enac.fr/en/architecture/linux-input/multitouch-howto.html#report. [1]

To get a bit further, I would start by modifying the trackpad endpoint (tp_ep field) in bcm5974.c to 0x83, bypass the mode switch (later problem), increase the message size to encompass the new report, turn on debugging, and test. Patch to do this attached.

If the above works, we should gain knowledge about the pre-mode-switch message size, know that we can extract data from the right endpoint, and be in a good position to test various mode switch settings (including the original one, since the endpoint mismatch may have caused a problem somewhere).

Thanks for testing,
Henrik

[1] The notion of moving the whole thing over to the hid subsystem is becoming more and more interesting, support on old machines can probably be guaranteed...

Created attachment 106311 [details]
bcm9574 testing patch aiming to support MBA6,2

Created attachment 106331 [details]
bcm5974 (v2) Attempt support for MacbookAir6,2

New version of the bcm5974 patch; also _use_ the defined TYPE3.

First set of results from the new patch, dmesg reports:
     bcm5974: bad trackpad package, length: 66
repeatedly for any touchpad event.  As expected, still no touchpad or keyboard functionality.

I will give the full HID report a shot in a moment.

Hitting a bit of an issue with the HID report as there is not a /dev/hidrawX device being created for the touchpad (with and without the provided patch sets).

Excellent - 66 bytes is a lot more than the 8 bytes that used to be the default for the emulated mouse device. What happens if you add more than one finger, is the message size still 66? I was hoping it would not be... Attaching a patch that will create _a lot_ of debug output, aiming to understand the message format used.

Ok, raw events might not be needed with the above path, but the hope was that the report descriptor file would contain more information than what was previously available via lsusb -v. If true, that information will be of interest.

Thanks for your tests, I feel we are making progress :-)

Henrik

Created attachment 106341 [details]
Examine the MBA6,2 message format

Created attachment 106351 [details]
dmesg of various touchpad events

dmesg results from the following actions (taken from the hid-replay test):

- drag one finger on the screen from one corner to the opposite
- release your finger
- land one finger
- land a second finger far enough from the first
- move your two fingers
- release the first finger
- release the second finger
- then, move your ten fingers on the screen and release them
- in the end, draw sth on the screen with the pen

I added at the end:
- one finger click (left-click)
- two finger click (right-click)
- three finger click (??)

Yes, indeed the length varies based on the action:
- one finger touch/click/drag: 66
- two finger touch/click/drag: 94
- three finger touch/click/drag: 122
- 10 fingers moving.. between 290 and 318
- The largest size I could get was 346

I will also repeat the above tests with the _large debug_ patch you provided.

Ok, if we are lucky, the size information might be all we need; it is actually consistent with the addition of four (unknown) values to the message header. The rest can arguably be assumed to remain the same, so attaching an attempt at a real, working patch.

Thanks,
Henrik

Created attachment 106361 [details]
Attempt at working patch for MBA6,2

Created attachment 106371 [details]
dmesg with debug of multiple mouse events

Might be unnecessary, as I will try the proposed working patch now, but I repeated the various mouse-event actions with the patch with message-format debug info.

The first attempts patch is a step forward -- the mouse is almost fully functional.

The mouse moves with one finger and scrolls with two fingers.  Clicks are picked up when 'tapping' the touchpad (single finger left-clicks and two finger right-clicks).

What doesn't work is the mouse 'button' (i.e. pushing down on the touchpad until it clicks).  Right-clicks via pushing the mouse button with one finger and left-clicks via pushing the mouse button with two fingers are both not registering.  As a result click-and-drag operations are not possible as well.

Of course, the keyboard is still nonfunctional as well.

Nothing of seeming interest is being reported by dmesg.

Great news! Regarding the button, I forgot to enable it rewritten patch, it should work now.

As for the keyboard, it needs the corresponding usb id as well, patch attached.

Henrik

Created attachment 106391 [details]
Working patch for MBC6,2

Created attachment 106401 [details]
hid-apple: add support for MBA6,2 keyboard

Keyboard is now up and functional.

However, the mouse 'button' is still not responsive. Should the button-endpoint be set to '0' in the bcm5974_config_table array? Or possibly the button-offset has changed in the tp_data?

The button endpoint was only used on the first generation of the MBA, it has not been in use for a long time (the old ep number could actually have been zero for all TYPE2 devices as well).

Looking through your debug output, it seems the button might be found as bit 8 in field 11 (the header probably operates on a byte boundary). Patch attached.

Created attachment 106411 [details]
bcm5974 patch, with new button field detected

After the latest patch, same results. No response to the button click.

Any other thoughts/debugging to help narrow it down?

Created attachment 106421 [details]
Raw packet data from a click

Attachment is a debug of the raw packet data when a click is made on the touchpad (touch, click and hold for 5 seconds, release click, remove touch).

It seems that you are correct, the click info is at offset 11.

When the click is invoked that index value changes from 1 to 101.

Created attachment 106431 [details]
Fixed bcm5974 for MBA2013

Simple fix to prior patch, casting the packet-data (dev->tp_data) to a 'const __le16' so that the BUTTON_TYPE3 index (11) indexes the correct memory location in the packet-data array.

All mouse (and keyboard) activity seems to be functional with this patch in conjunction with the prior hid patches.

I will attach a single full source tree patch next.

Created attachment 106441 [details]
Fixes for MBA2013 touchpad and keyboard issues

Patch for 3.9.8 kernel source to include support for the MacBook Air 6,2 (mid2013) touchpad and keyboard.

Tested on the MBA-2013 13-inch hardware and regression tested on a MBA-2012 11-inch.  Both function as expected.

Unable to test on the 3.10-rc7 -- unable to boot the MBA-2013 laptop at all with this kernel version.

Excellent, thanks for testing. The new header data has apparently been inserted somewhere in the header, with the button byte position shifted accordingly. The final two patches are attached below. I will push these as soon as I

a) get a confirmation that it works
b) get a real name to add as reported-by and tested-by ;-)

Cheers,
Henrik

Created attachment 106451 [details]
Final HID patch

Created attachment 106461 [details]
Final bcm5974 patch

Great!  I tested your final two patches and, as expected, they work fine. Job well done.

BTW, what constitutes a 'real name'?

Thanks for the help, I'm sure many will enjoy linux on their new MBAs.

Good to hear!

And if this is your real name, I sincerely apologize. I will push the patches now. :-)

Thanks again,
Henrik

I have a MacbookAir 6,2 (also 2013 model), and this patch does not seem to work -- running 3.11-rc6 atm.

Do you also need to blacklist some modules for this to work?

Adding 0x0290 makes the keyboard work too. I also tried to apply the patches for the mouse driver but this made the touchpad unresponsive.

Reworked this patch and incorperated somebody else's patch, makes my keyboard and touchpad work perfectly :-) See https://launchpadlibrarian.net/148354532/macbookair-3.11-rc6.patch for the patch I used/created.

We got the ANSI/ISO numbers wrong from the beginning. One of the early tested machines seems to have been labelled ANSI when in fact it was ISO. We should have this table instead:

#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI    0x0290
#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO     0x0291
#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS     0x0292

I know Linus T has an ISO machine labelled 0x0291, and Brad, it seems you machine is indeed ISO as well, correct?

Thanks,
Henrik

(In reply to Henrik Rydberg from comment #42)
> We got the ANSI/ISO numbers wrong from the beginning. One of the early
> tested machines seems to have been labelled ANSI when in fact it was ISO. We
> should have this table instead:
> 
> #define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI    0x0290
> #define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO     0x0291
> #define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS     0x0292
> 
> I know Linus T has an ISO machine labelled 0x0291, and Brad, it seems you
> machine is indeed ISO as well, correct?

For what it is worth, my MacBook Air 6,2 with an ArchLinux 3.11.1 kernel build has the following:

/* MacbookAir6,2 (unibody, June 2013) */
#define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI    0x0291
#define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO     0x0292
#define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS     0x0293

And that works for me.  The values you give result in my losing the ~ and ` key on the US keyboard and instead it is replaced with < >.  I just noticed this problem today in an updated 3.11.2 kernel from Archlinux.  That release includes the values you list above and results in the mismatched keys.



> 
> Thanks,
> Henrik

> For what it is worth, my MacBook Air 6,2 with an ArchLinux 3.11.1 kernel
> build has the following:
> 
> /* MacbookAir6,2 (unibody, June 2013) */
> #define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI    0x0291
> #define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO     0x0292
> #define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS     0x0293
> 
> And that works for me.  The values you give result in my losing the ~ and `
> key on the US keyboard and instead it is replaced with < >.  I just noticed
> this problem today in an updated 3.11.2 kernel from Archlinux.  That release
> includes the values you list above and results in the mismatched keys.

And what USB ID do you have on your machine? (lsusb)

(In reply to Henrik Rydberg from comment #44)
> > For what it is worth, my MacBook Air 6,2 with an ArchLinux 3.11.1 kernel
> > build has the following:
> > 
> > /* MacbookAir6,2 (unibody, June 2013) */
> > #define USB_DEVICE_ID_APPLE_WELLSPRING8_ANSI    0x0291
> > #define USB_DEVICE_ID_APPLE_WELLSPRING8_ISO     0x0292
> > #define USB_DEVICE_ID_APPLE_WELLSPRING8_JIS     0x0293
> > 
> > And that works for me.  The values you give result in my losing the ~ and `
> > key on the US keyboard and instead it is replaced with < >.  I just noticed
> > this problem today in an updated 3.11.2 kernel from Archlinux.  That
> release
> > includes the values you list above and results in the mismatched keys.
> 
> And what USB ID do you have on your machine? (lsusb)

Bus 001 Device 004: ID 05ac:0291 Apple, Inc. 

US purchased Macbook Air 2013 6,2 13" display.

In order to work around the issue with the ANSI USB ID assignment, I have to manually set the layout:

[seanvk@prairie ~]$ cat /etc/modprobe.d/hid_apple.conf 
options hid_apple iso_layout=0

I did not have to do that in 3.11.1

Sean

Thanks for that. It is logical, in the sense that it was this new and odd behavior that created a problem in the first place; apparently both 0290 and 0291 are being sold with a US keyboard. We will have to find another way to map the keyboard language in the kernel...

Thanks,
Henrik

All,

Thanks so much for working on these issues! I just got a MacBookAir6,2 the other day, and I am enjoying the fruits of your labor.

I apologize if this is not the right place to post this information, but I can confirm that I am also experiencing this problem:

(In reply to Sean V Kelley from comment #43)
> And that works for me.  The values you give result in my losing the ~ and `
> key on the US keyboard and instead it is replaced with < >.

lsusb reports:

Bus 001 Device 003: ID 05ac:0291 Apple, Inc.

I'm running:

Linux vertex.malexmedia.net 3.11.6-200.fc19.x86_64 #1 SMP Fri Oct 18 22:34:18 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

The hardware is a new MacBookAir6,2 with 13" display, purchased in the US.

Before I found this bug report I created a new bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=1025041

Thanks guys.

All,

I just tested this again with 3.12 release. My keyboard's backtick key is still misbehaving per comment #43.

I am currently working around this bug using: echo 0 > /sys/module/hid_apple/parameters/iso_layout

Of course this is out of the reach of your average user, so shouldn't we solve this? Is there any way I can help with troubleshooting or testing this bug?

Thanks.

Please try this bug with latest kernel image.