-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MacBookAir6,x and 7,x (Mid-2013/Early-2014 and Early-2015/2017) support #65
Comments
Given the dmesg and other info above, it looks like the SPI interface is properly enabled (and the USB interface disabled), so that's good. And especially the fact that the keyboard backlight is working is encouraging (does the caps-lock light also work, btw?). Now to look at the keyboard and touchpad, can you enable debugging in the driver of the keyboard inputs:
And let me know what you see in dmesg when you type on the keyboard (there should basically be an applespi "Keyboard Event" packet dump for every key action) - this should let us know whether the driver is receiving and processing keyboard events or not. Assuming keyboard events are being received, the next thing to do might be to take a look at libinput's info (assuming you're setup is using libinput): does running |
About the backlight: it actually worked in spi mode even before I did anything with applespi (even back when I ran 16.04 with kernel 4.10, the backlight worked even though actual keyboard input didn't.) This is apparent after looking at /sys/class/leds:
echo'ing values to the brightness file in spi::kbd_backlight does nothing. echo'ing values to the brightness file in smc::kbd_backlight DOES work perfectly (range of 0-255 brightness levels, nice!) So it appears here that the keyboard backlight is controlled by applesmc, and I confirmed this theory by booting without applespi. Keyboard backlight remains adjustable, while the spi::kbd_backlight device disappears. This might be a key difference between the Macbook8,1 and MacBookAir7,2: the keyboard backlight is controlled by applesmc in MacBookAir, while it is controlled by bcm5974 on MacBook8,1? That's why there's the spi backlight device I assume. I am not sure how to test the caps lock key on the keyboard, I tried poking around in /sys/class/leds/input4::capslock but to no avail. (input17 is my usb keyboard) Anyways, so I went ahead and ran the command exactly as you said.
I then did
It appears like it is not receiving the packets. Interesting... Any thoughts? Also, thank you a lot for taking time to write a driver for proprietary hardware. A lot of people appreciate you, and it is wonderful that you took the time to do it. Thanks! FYI: System is Ubuntu 18.04 development branch, stock kernel 4.15.0-15 from ubuntu. |
Thanks. So, no keyboard packets. Hmm: can you turn on a bit more debugging:
This will also print the interrupts received and dump any unknown packets. |
Yup:
just mashed all the keys... should I reboot to activate something I missed? Maybe a Linux 4.17-git kernel?
|
Wow, no interrupts. Can you check your DSDT and see what GPE it declares for the keyboard/touchpad? (look for the --- a/applespi.c
+++ b/applespi.c
@@ -1678,6 +1678,7 @@ static int applespi_probe(struct spi_device *spi)
acpi_format_exception(result));
return -ENODEV;
}
+ pr_info("GPE: %llx\n", gpe);
applespi->gpe = (int)gpe;
result = acpi_install_gpe_handler(NULL, applespi->gpe, Next, given the GPE, show me the output of
(on my system, the GPE is 0x17, btw). |
Yup, thankfully I have a hackintosh background, so I speak ACPI and AML now :)
GPE=0x1C EDIT: also looked at a dsdt from a MacBookAir6,2: https://github.com/Ramalama2/Apple/blob/master/1.%20Tables/MacBookAir6.2/DSDT.dsl It also has the same GPE and has the spi device defined in exactly the same way (not surprising, since 2014 is a processor bump of 2013 (same id of MacBookAir6,x), and 2017 is a processor bump of 2015 (same id of MacBookAir7,2 since only 13 inch is available.) 6,x is Haswell, 7,x is Broadwell. A fix for this would fix 4 generations and 4 years' worth of MacBook Airs, so if this gets worked out all those would work. Just FYI. |
What is the output of
|
Sorry about the delay! Here:
|
Thanks. Hmm, so the GPE is enabled, but apparently not being triggered (well, it was only triggered once, so obviously not on each keyboard/touchpad event, like we expect). As this point I'm not really sure how to proceed. We could in theory re-introduce polling of the keyboard/touchpad, but for various reasons I really don't think we want to go there. Instead, the question is how to get this interrupt/GPE working. Btw., does the output (or anything else) change if you manually clear the status?
|
I've been busy, sorry... The only change appears to be from:
To:
dmesg shows no change, xinput still doesn't show any data from either SPI device, and dmesg shows no change. This is really a head-scratcher. I can patch the ACPI tables if necessary, I've already done so on an older Mac on Ubuntu to fix thunderbolt (with the _OSI call patching to report Darwin every time.) Knowing that the interrupts are over GPIO, maybe we need to enable them via a special method in the ACPI tables? FYI the MacBookAir6,2 tables in the github link are identical to mine, so that's a good way to look at the DSDT if we need to. Sorry if I'm dragging this too far, it's a lot, I know, and I appreciate your work. Also, from reading applespi.c directly, I noticed this:
Later, I noticed this:
From my amateur knowledge of C, I think you are using a conditional statement to determine model info from DMI like this pseudocode:
It looks like you are special-casing each model that needs specific info to work, and using the default values (that are known to work) for all the other models. Going back to the first copy and pasted comment, it says that only MacBookPro12,1 has both spi and usb interfaces. The MacBook Airs since 2013 have both spi and usb interfaces, very much like the 12,1 Macbook Pro (and we know because my trackpad and keyboard work without apple_set_os and appear as USB devices.) Since the MacBookPro models are special-cased, perhaps a quick fix in the code would help? As to that I don't know sadly how. MacBookPro12,1 is not special-cased, so how is the logic in the code flowing for the MacBook Air? Maybe finding out how the Air goes through the code would help us understand what needs to be fixed? Maybe seeing how each dmi statement returns for the Air would help see what code ends up being run for the Air. Just suggestions. Lastly, I saw that you forked this repo and you updated it more recently that cb22. Should I clone and compile your fork instead? I am currently using cb22 in my DKMS script and his version is the one I'm working with. I appreciate your work, truly. You have done something awesome, thanks for the driver and sorry to ask so many questions! |
@newperson1746: That code comment that the MBP12,1 is the only machine with both, USB and SPI, was written by me and is clearly erroneous. I thought that's the case but I recently came across a video by Louis Rossmann which proves that MacBook Airs also had this. Feel free to submit a pull request rectifying the incorrect code comment. Could you provide a little more detail which Thunderbolt functionalities are enabled by apple_set_os? |
The MBA6,2 DSDT linked above seems to be missing the device properties and _CRS resources for the SPIT device (clock etc), I guess we need to define defaults for this case. :-( |
Yeah, that's what I thought too... About the thunderbolt functionalities: I came across this article here that details the DSDT's checks. I can verify that not setting acpi_osi=Darwin will result in the thunderbolt controller being powered down by Linux (or at least, I can't hotplug the thunderbolt --> ethernet adapter, I have to have it plugged in before GRUB2 efi.) Setting acpi_osi=Darwin enables thunderbolt hotplug and I can hotplug the ethernet adapter as I wish. Thunderbolt also keeps on working after sleep. Should the PR go to cb22/macbook12-spi-driver or roadrunner2/macbook12-spi-driver? roadrunner's fork was updated more recently. |
@newperson1746 Sorry, I missed your edits. Regarding the code and the Regarding the repo's: my clone is mainly for two things, 1) the touchbar driver, and 2) things that aren't ready/meant to be pulled into the main repo. So please submit your PR to cb22's repo. |
@newperson1746: Could you add a debug printk to applespi's If you're talking to the device with the wrong clock, it wouldn't be surprising if the GPE never fires. As for Thunderbolt, since commit torvalds/linux@7bc5a2b it should no longer be necessary to pass |
Here are all the ACPI tables, including the dynamic ones (from /sys/firmware/acpi/tables and /sys/firmware/acpi/tables/dynamic) and disassembled in the ./disassembled folder using iasl -da -dl. I am not too great at writing C, so could you give me a hand in adding printk? Sorry to have gone this far in problem-reporting without having real C experience... I think I confused apple_set_os and acpi_osi=Darwin. You are right about not needing to pass OSI anymore. apple_set_os basically enables the discrete gpu in dual-gpu macbook pros, enables the raw battery protocol (instead of the acpi-compliant one, but it works in linux nonetheless) and switches the keyboard + trackpad (bcm5974) into SPI mode. Also note that the keyboard backlight turns on and is controllable as an led with range 0-255 in /sys/class/leds/smc::kbd_backlight, even without applespi loaded (applesmc must control the backlight through the SMC, and not the actual keyboard interface.) Well, it's great to see great people working on a great driver. Thank you for your support. |
Thanks for the DSDT - that looks good, i.e. it contains the expected _DSM method for the spi device, from which we extract various parameters for the SPI driver. And that explains why the applespi driver loads fine. It's not really necessary now, but just for kicks, here is basically the patch @l1k was asking for: --- a/applespi.c
+++ b/applespi.c
@@ -1638,6 +1638,16 @@ static int applespi_probe(struct spi_device *spi)
if (result)
return result;
+ {
+ struct acpi_device *adev = ACPI_COMPANION(&applespi->spi->dev);
+ const union acpi_object *o;
+
+ if (!acpi_dev_get_property(adev, "spiSclkPeriod", ACPI_TYPE_BUFFER, &o))
+ pr_info("spiSclkPeriod: %llu\n", *(u64 *)o->buffer.pointer);
+ else
+ pr_warn("Property spiSclkPeriod not found\n");
+ }
+
/* set up touchpad dimensions */
applespi->tp_info = *(struct applespi_tp_info *)
dmi_first_match(applespi_touchpad_infos)->driver_data; Compiling and loading the new driver should result in a 'spiSclkPeriod: 125' message in dmesg. |
Hi everyone, The log from a boot with the spi controller enabled with apple_set_os: The Caps Lock messages then loop along with the -110 errors. How should I begin? |
Sorry for the delay. First of all: what version exactly of applespi are you running? Next, either something's changed or I misread things last time, because your latest log seems to indicate the GPE is being received and handled - great! Though to confirm, could you enable a few more debug bits? I'm guessing you're booting with something like Finally, the problem now appears to be that the SPI device (keyboard/touchpad) is not responding. I see several potential reasons for this:
To double check the SIEN call, can you apply the following patch and then send me the --- a/applespi.c
+++ b/applespi.c
@@ -799,6 +799,7 @@ static int applespi_enable_spi(struct applespi_data *applespi)
/* check if SPI is already enabled, so we can skip the delay below */
result = acpi_evaluate_integer(applespi->sist, NULL, NULL, &spi_status);
+ pr_info("SIST before: res=%d sts=%llu\n", result, spi_status);
if (ACPI_SUCCESS(result) && spi_status)
return 0;
@@ -809,6 +810,9 @@ static int applespi_enable_spi(struct applespi_data *applespi)
return -ENODEV;
}
+ result = acpi_evaluate_integer(applespi->sist, NULL, NULL, &spi_status);
+ pr_info("SIST after: res=%d sts=%llu\n", result, spi_status);
+
/*
* Allow the SPI interface to come up before returning. Without this
* delay, the SPI commands to enable multitouch mode may not reach |
Hi,
I have this very peculiar Macbook Air:
I believe that MacBook Air 6,2 (2014) also has spi input devices, but you normally don't see them as unless apple_set_os detects macOS, it exposes the USB interface of the input devices. Touchpad and Keyboard work in USB mode (applespi outputs something about device is in usb mode when booted normally via uefi grub) but using apple_set_os.efi to trick the efi into thinking its macOS results in the raw spi device being exposed. It uses AppleIntelLPSS and AppleIntelHSSPI just like the normal MacBook8,1. It has a Wildcat Point GSPI Controller with identical pci id's to the MacBook8,1:
Some progress does occur when booting:
However, it does not appear to find any master spi controllers or the like. Xinput shows some shenanigans too:
But, they don't work on any part of linux boot or after, except on the grub screen.
xinput test 13
andxinput test 14
do nothing.Amusingly, the keyboard backlight works without any additional work (it turns on during boot.) Using apple_set_os.efi is beneficial since it unlocks some thunderbolt functionalities in linux that normally are reserved for macOS, and it would be nice to get it to work on one more device, and there is also the added benefit of a few more EFI features that work with this trick.
Thanks for doing this awesome work on this driver! It has helped so many people with their new devices, and I hope we can get this to work on this peculiar Air.
The text was updated successfully, but these errors were encountered: