ambient light sensors work, at least on macbook 13,1 #16
Comments
|
I can confirm this: (notice the lux=2) |
|
That's interesting. The MacBookPro13,2 shows none: So one more piece of hardware which differs between the models. 😫 |
|
From some MacBook8,1 Given that the MacBook8,1 and the MacBookPro13,x were rather large redesigns my current guess is:
|
|
@Dunedan that's an interesting point about the keyboard backlight perhaps being controlled by SPI. I'll try do some SPI captures in Windows and see if changing the keyboard backlight leads to any activity. |
|
@Dunedan good news! It's exactly that. I did a quick decode of the packets from Windows and added what I thought was controlling the keyboard backlight as an init_command to the driver, and the keyboard indeed lights up. If you add: to I captured the trace for 3 different settings, level 1, level 2 and off (there are many more, but I didn't feel like going through them all - there's probably a pattern too). In that same order, they are: |
|
OMG, this is awesome! 🎉 🍾 I'll try it out the next days and will report back if it works the same way for the MacBookPro13,x as well. |
|
I can confirm it works on a MacBookPro13,2 as well. 👍 |
|
Great. I should add this to the driver then; I don't have much familiarity with backlight devices on Linux, but I see the |
|
Maybe @roadrunner2 is familiar with this area as well. |
|
@cb22 Awesome! I spent some time a few weeks ago looking at the smc's items and came to the conclusion that neither the light sensor nor the keyboard backlights were controlled/attached to it, and so started suspecting the keyboard backlight might be controllable via SPI - this is fantastic that you figured it out. Also, yes, the keyboard backlight goes under LED's class, not the backlight. As to the format of the packets sent and received, I have some info on the details (figured out several fields) - will post more info soon, as well as a pull request to create/use appropriate |
|
FWIW, on some older macbooks the light sensor doesn't work either. On some it returns values between (0,255), and others (0,3). The latter ones are probably broken, but I tried (and failed) to debug them. My guess is that there's a problem decoding the data the sensor sent (it being two bytes), but it was slightly beyond me. |
|
So, I finally looked a bit into my theory of the ambient light sensor being connected to the T1 chip and exposed via iBridge in the TouchBar-models. That motivation was partially based on recent statements, that Apple's T2 chip in the new iMac Pro takes over some of the SMC functionality. So why shouldn't the T1 already do that? 😉 And I got at least something interesting: I believe the fact that there is a reaction at all from the ambient light sensor via USB proves my point that it's connected through the iBridge instead of the traditional SMC-way. |
|
@l1k has another theory (which sounds pretty plausible):
|
|
@Dunedan I took a look at your usb traces: the "problem" is that they involve one of the new usb devices that show up when the extended mode is used. As such I'm a bit sceptical about them. l1k's theory, however, sounds quite plausible - now we need somebody to get traces (if possible) from Windows so we can reverse engineer and implement the protocol. |
|
I tried to find the macOS driver among the 10.12 kernel extensions to no avail. If you invoke |
|
Here's the full |
|
There's no ALS driver attached to the UART slave, it's merely exported to userspace via: Is there a daemon that has those files opened? There's something else which seems to support @Dunedan's theory that ALS is handled by the iBridge: I did a quick grep over the extracted 10.12.5 combo update I had lying around here and noticed something else of interest: The file You may want to repeat the grep for cu.lpss-serial over your OS installation, I don't have a full OS install here, only this combo updater. |
|
@1lk Sorry, forgot to mention that: no, |
|
So one theory would be that the ALS can be accessed in two ways, via USB and via UART. They've done things like that before. E.g. on the MacBookPro12,1 the keyboard is attached to both, SPI and USB. The MacBook8,1 which came out 1 month later left the USB pins on the keyboard controller unconnected. I'm not sure but I think that on the MBP12,1, the BIOS switches to USB if Windows is booted and to SPI if macOS is booted, subject to the custom EFI OS identification protocol that's also used to turn off the integrated GPU on MBP11,3+ if anything else than macOS is booted. You're writing above: they involve one of the new usb devices that show up when the extended mode is used Is this extended mode also available on Windows or is it macOS-only? If the latter, it would mean that Windows probably uses the UART interface to access the ALS. But because the ALS is part of the iBridge, it would mean there's not one but two serial backdoors. I find it odd that Apple would increase the attack surface like this. It is also weird that they hardcoded the tty into the EmbeddedOSInstall.framework. Seems sloppy from a maintainability point of view, what if they want to attach the iBridge to a different UART than lpss-serial1 on future models? It would have been more logical to search for the UART labeled "apple-uart-soc" in the I/O registry to find out its tty. They can't do that without shipping an updated DSDT because they botched the _CID names on the MBP13,2 and MBP14,2 where this UART is labeled "apple-uart-ssdc". |
|
Looking at EmbeddedOSInstall.framework in the disassembler right now, the device is used by an EOSSerialLog class. The baudrate etc. are all hardcoded. Hm, this looks like a debug facility. |
macOS only.
But only if the Windows drivers provide access to the ambient light sensor. Do we know if they do? |
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
|
@Dunedan, you were right of course about the ALS being part of the iBridge. I was reading up on USB HID report descriptors etc a short while back, and then took a closer look at those that the iBridge HID interfaces declared, and lo and behold I found a HID sensors descriptor containing the reports for the ambient light sensor. I've now implemented the basic functionality for that in the One slight ugliness is that while I've set things up so that the sensor only reports changes over a certain threshold (hysteresis), that threshold is a fixed, absolute value (defaults to 25, the value I saw being used in the USB traces from windows). But tracing the USB interface under MacOS it looks like they set up a relative threshold of around 15% to 20% - this gives better sensitivity at low values and fewer events at large values. I just can't figure out how MacOS sets this up, though (the sensor feature report only allows setting an absolute threshold, which is what I use, so this must be somewhere in one of the apple-specific reports, but no clue which). Lastly, there's a bug in |
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
|
Great work @roadrunner2 for figuring out all these details! 👍 I did try to get it to work on my MacBook Pro. One problem I stumbled upon was that After that
I thought about that as well and it probably makes sense to have separate drivers for each function of the iBridge, as it fulfills multiple roles, which might also differ from device to device. E.g. I expect the iMac Pro to have its ambient light sensor exposed in the same way. So the ambient light sensor would probably fit in some kind of "applesmc2"-driver.
That sounds odd, at least if there is no obvious way to manually override that automatic behavior as that's possible with macOS. Maybe that's related to the other unknown configuration interface, which could allow manual control over that as well. |
|
FYI: With KDE the ambient light sensor doesn't do anything, as using its data isn't implemented yet. There is a feature request for that though: https://bugs.kde.org/show_bug.cgi?id=353463 |
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
|
@Dunedan wrote:
Thanks for pointing that out! I updated the README now (you actually just want to
Yes. The fix has now been applied and is part of the just released version 2.5, so I suggest grabbing that.
After looking at stuff a bit, I'm planning on creating an mfd driver called apple-ibridge with sub-drivers for the touchbar and ALS.
There are 5 proprietary HID reports on interface 3, only one of which we have partial knowledge of (for dimming and turning off the touchbar display) - the rest I have no clue what they do. I agree, it's quite probable that one of them allows controlling this. |
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
I've split up the |
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
|
Thanks @roadrunner2 for adding support for the ambient light sensor as |
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
The iBridge also manages the ALS and exposes it as a standard HID light sensor on the second USB HID interface. However, we cannot make use of the existing driver support for such devices for several reasons: * the hid-sensor-als driver is part of the hid-sensor-hub which in turn is a hid driver, and you can't have more than one hid driver per hid device. * while the hid-sensors-als driver stores sensor readings received via interrupt in an iio buffer, reads on the sysfs .../iio:deviceX/in_illuminance_YYY attribute result in a get of the feature report; however, in the iBridge case the the illuminance field of that report is always 0. Instead, the input report needs to be requested. For these and some other smaller reasons we (re)implement the necessary report processing etc ourselves here. And because we do so, the implementation is fairly bare bones. E.g. it does not implement iio buffers and triggers, instead only supporting on-demand reads via the sysfs in_illuminance_input attribute. But this is all that is needed for desktops running the iio-sensor-proxy (used by Gnome and possibly others). This addresses Dunedan/mbp-2016-linux#16 .
@Dunedan Just wanted to let you know that I noticed that if I put a hand above the screen (right above the camera) the screen brightness autoadjusts).
At least that's working out of the box.
The text was updated successfully, but these errors were encountered: