Patched touchbar driver not working in kernel 6.0 #189
Comments
|
Yes, I can confirm the provided error but it is possible to easily overcome it as described by the following comment: roadrunner2/macbook12-spi-driver#67 (comment) Still to be published a proper fix upstream to the repository, but at least it is possible quite easily to make it work. |
|
yeah that's right. I forked it to remove the saving functionality. |
|
@marc-git I still can't compile it under 6.3.8-200.fc38... Building module: |
|
I used the macbook12-spi-driver-dkms from the AUR. It uses a patch. |
I can delete that from dkms.conf but it still won't work. |
that patch is not working for me in 6.6.13 |
|
patch doesn't work for me on Fedora 39 (6.6.14) or openSUSE Tumbleweed (6.7.2). (note however, did work flawlessly on Debian Stable/6.1.0) perhaps someone smarter than me would know a fix? in a last ditch effort I tried the t2linux fork (https://github.com/t2linux/apple-ib-drv), and I ran into the same issue. |
|
The build error with .remove is trivial to fix, but for me the touch bar doesn't work with 6.6 regardless. The driver detects it, registers the input device, but the touch bar just stays black. It worked ok on Linux 6.1 with the same driver. It randomly worked twice, but I don't understand why and could not reproduce this. |
Could this be due to |
|
I don't have usbmuxd running at all. I am now building a 6.1 kernel again to see if something else changed (like accidental deletion of the firmware from the efi boot partition). If things still work with the old kernel I'll try my luck with a bisect. |
|
With Linux 6.1.76 the touch bar is working with @marc-git 's driver. With 6.4 and 6.6 it doesn't work most of the time. So I have a baseline for bisecting. A problem is that in "bad" kernels it is randomly starting up, and I haven't figured out why - I estimate that it works 10% of the time. So if the touch bar starts up I have to reboot a few times to make sure the kernel revision is really working and not randomly (un)lucky. |
I patched /usr/lib/udev/rules.d/39-usbmuxd.rules according to: Instead of using a new script to fix this issue. That works also. Without the patch it was not lighting up.
I run Arch Linux, which is shipping the latest kernel version.It's been through server 6.6.x versions. It's on 6.7 by now and haven't had any issues with the TouchBar. |
Are you running with just different usbmuxd rules? No home brew spi drivers? |
yes.
just the one from the AUR package, which has a patch build in. So just I deleted the generated stuff from the aur package and did a makepkg again, no errors. It is up to date, I update my system regularly. So in order to get it to work I do:
|
|
My bisect ended with this kernel commit as the first bad one: Suffice to say, this doesn't make much sense. Only with some unlucky random side effect would SCSI-related changes break a USB HID device. I'll try to build the source branch of that merge and see if I can reproduce the issue. If that's the case I can bisect over the 142 commits the merge introduced. |
|
@stefand that took some effort 💪already |
|
So my previous bisect ended up with a non-sensical commit because the touch bar luckily worked 3 times with a "bad" kernel. On a second attempt I ended up with this commit as breaking the touch bar on my system: This makes more sense - it talks about T2 macbooks pro. My MacBookPro14,3 has a touch bar, but not a T2 chip. That would also explain why the touch bar driver works fine for some people here. |
|
Reverting e04955db on a 6.6 kernel makes the touch bar come up reliably. I guess the problem only affects pre T2 macs. Sadly I don't know the USB technical details to figure out how to fix this properly. Since the touch bar driver still lives out-of-tree it will be tricky to get the kernel devs to fix it. I'll try to get the attention of the t2linux people. |
|
@stefand I have MacBook 14,3 (A1707). In Mac OS System information, under hardware->Controller I see Apple T1 Security-chip. Firmware 14Y910. The AUR patch I use hasn't been updated, checked that too. I do run with the I act like I'm Mac OS trick. Found here. I use rEFInd to be precise, shouldn't matter. Maybe that matters. I boot into Mac OS (Ventura 13.6.4) from time to time too and run the updates in Mac OS. This sometimes updates firmware, could be something too. Though Ventura doesn't receive all the updates anymore. I might be missing something completely here, but I just don't get why it's working on mine, except I'm on 6.7.4-arch-1 kernel version. |
|
@gjvanderheiden the touch bar works for me occasionally with an unmodified 6.6 kernel. I don't know if this is runtime luck or has something to do with how the kernel and/or driver are built. I tried updating to 6.7, but it doesn't change the behavior. Maybe the presence of usbmuxd influences things in a positive way, at least when the workaround discussed in this bug is used. |
@stefand Any luck with them? |
|
@marc-git There is no response yet to the bug I filed. |
|
You can try https://github.com/almas/macbook12-spi-driver/tree/touchbar-driver-hid-driver |
|
@almas I don't think this will help on pre-T2 macs. The changes you made to the module are the already discussed build fix, but I don't see anything that would fix the regression introdced by kernel commit e04955db6a. |
|
@stefand I don't know much about it. |
|
updated my fork again to keep it compiling. Still not working, even with suggestions from @gjvanderheiden to change the |
|
@stefand still no answer on t2linux. I wonder if @roadrunner2 would know what is causing this. My MBP is running slower and slower on the newer OSes so I am switching to Linux more often and its getting on my nerves now. What are the options here? I guess:
|
|
No answer. Sadly I don't have the time to follow up. The only thing I checked is if a 6.8 kernel magically fixed the bug. The result is as expected no, the dark touch bar is not fixed. The commit that causes the regression still reverts cleanly though. Since the macbook is just a tool to an end I've reverted the commit locally. |
I think a t1linux project would be a good idea solely to document stuff (like audio now mostly working with davidjo's driver on touchbar macs), not sure if we'd be able to pull in support like t2linux unfortunately :l, the 2016/2017 macbooks are at worst a year (or two) away from losing any form of official support on both proprietary operating systems. (Monterey/Windows 10 in mid 2025, Ventura in 2026), and if you have a touchbar macbook you're basically damned to a far more hassled experience on Linux (moving aside the touchbar, the bcm43602 STILL still half functions with the .txt file, and the .txt file isn't even read on Fedora/Fedora-based distros for some reason, and drowning in suspend or having everything break in said resuming with the "fix" is still a major issue on these laptops regardless of touchbar or not). If we want these laptops to remain usable/up-to-date within the next 3 years, we'd probably have to figure out something soon, so I think starting such a project now wouldn't be a bad idea. I wish I had the skillset to contribute in a meaningful manner, but I don't see myself having this laptop (MBP2016/13in+TB) around for much longer, especially as my butterfly keyboard deteriorates further and further. (Note: I also primarily use Linux on mine (Currently EndeavourOS/Arch), but I keep it docked and hooked up so I can work around most of the issues, though undocked i find myself reverting back to Monterey to avoid dealing with half assed WiFi and borked suspend) |
|
On my 14,2 Macbook Pro the touchbar wasn't lighting up either on the latest kernels, so i had to use stock Fedora 38 for some time, but it suddenly started working on newer kernels and other distros (Void and Artix). The only remarkable change i made on my system was installing unsupported macOS Sonoma through OpenCore Legacy Patcher. Could it be firmware related? |
|
On which Linux kernel version(s) is it working? I tested an unmodified 6.9 and it still needs the revert. I am running 6.10 now, but with e04955db reverted. I didn't (yet) test 6.10 without this change. It is possible that a firmware update improved something, but I find it unlikely, though not impossible, that an officially unsupported OSX version would bring a firmware update for this hardware. Also even with "bad" kernel versions the touch bar started up randomly. My gut feeling says it works 10% of boots, so if you booted 3 or 4 times a lucky streak is certainly possible. |
|
I'm running latest stock kernel on Void Linux (6.6.46_1). |
|
Fwiw it is still broken for me on 6.10. I have to revert the mentioned commit. |
|
Tried it again using Gentoo's kernel binary version 6.6.47 and the issue came back again, could only make it work once. |
|
So that rules out that MacOS sonoma did anything? This might be a race condition. I am not familiar with Dracut, but I think what it changes for this particular case is that it puts the touch bar driver into the initrd. In my case the apple-ibridge and apple-ib-tb modules are not in the initrd and are loaded in the boot process when udev (or rather systemd-udev) loads a bunch of drivers. That is likely to change the module load order and might change the order in which USB devices are initialized. |
|
How hard would it be to just write a bunch of dkms modules that take care of the wifi .txt fixes as well as reverting the commit for the touchbar? In my humble opinion the largest barrier to entry for working on linux on T1 macbooks is how everyone has to first read through this entire thread, as well as the wifi thread etc. Roadrunner's informational page is long outdated, and there is no updated, well documented source of all the latest information for getting linux working on T1 macbooks. I have a MBP 13,2 sitting unused ready for active development. If there's enough interest I wouldn't be opposed to starting the repo myself. We can focus on first tackling this barrier to entry, and then hopefully we will see more interested people. T1 macbooks are near death in terms of official OS's, now is the time to get the linux effort going. I will most definitely need help though. |
I am happy to read that it works for you on 6.1, but I am not able to compile it on 6.1.0-25 from Debian 12 fresh install. any clue what is this compilation error? I have experience on kernel module compilation, but I made sure I have the linux-header package at least. |
Can you post how to fix that trivial error with the It is not trivial at all here ;) |
|
Thanks for the tip. Tried but no success |
|
foice, when I called the fix "trivial" I meant it for someone who is proficient in the C programming language. If you don't know the language it isn't easy of course. I don't know why Almas' code fails for you, but I can try to describe what you need to change to fix your original error: in apple-ibridge.c change
i.e., change the "int" to "void". Then at the end of the function change almas/macbook12-spi-driver@3355ca7#diff-984f3aa56499b4f3f2430ce4ff6da90aa14c970c7cf0acbc11790f566f619926 shows a diff that you can try to download and apply instead of hand editing. |
|
doing the opposite change of what you wrote did the trick, i.e. it works if I use the function as int. Then I did |
You're using Kernel 6.1.xx right? I think that is no longer relevant to the discussion here. We are looking at changes after the kernel modification that stefand rolls back. |
The patched touchbar driver from @PatrickVerner is no longer working on the latest kernel. The compile error I get is
applespi.c:1810:38: error: invalid application of 'sizeof' to incomplete type 'struct efivar_entry'Confused why this suddenly became a problem. Anyone want to hazard a guess at a solution?
The text was updated successfully, but these errors were encountered: