You are not logged in.

#1 2018-07-09 19:07:56

marian
Member
Registered: 2017-09-19
Posts: 3

[MacBook Pro 2,2] No Screen Brightness Control

Some comments

This issue is probably unique to this very specific hardware combination but might affect other architecture hand over configurations that boot 64bit Linux from a 32bit EFI.
The machine in question is a MacBook Pro 2,2 (Late 2006). This model and a few other from these years are notorious for having a custom 32bit 1.x EFI instead of a BIOS/UEFI and are paired with a 64bit architecture CPU. Specifically in my case 2 x Intel® Core™2 T7400 @ 2.16Ghz (Core 2 Duo).
The EFI is further capable of booting with CSM thus generating a BIOS for other operating systems like Windows, by design through the propietary BootCamp software from Apple. This has the drawback of not being able to access efivars.

I comletely wiped the hard drive on this laptop and installed Arch. The EFI is actually quite interesting since it boots really anything as long as it is called BOOTIA32.EFI and placed in any partition formatted as of the EFI spec or even HFS+ (after all it's Mac...). So my ESP is a simple VFAT /dev/sda1/ mounted at /boot containing the standard path /boot/EFI/BOOT/ and that's where my BOOTIA32.EFI is located, in reality being Grub2. It's really easy to install Grub this way with --removable --target=i386-efi.

More Detail

The GPU in this machine is a (AMD)ATI RV530/M56-P (Mobility Radeon X1600). Issuing # lspci -v on this device gives some details I can not interpret myself:

    Flags: bus master, fast devsel, latency 0, IRQ 30
    Memory at 80000000 (32-bit, prefetchable) [size=128M]
    I/O ports at 3000 [size=256]
    Memory at 90300000 (32-bit, non-prefetchable) [size=64K]
    Expansion ROM at 90320000 [disabled] [size=128K]
    Capabilities: [50] Power Management version 2
    Capabilities: [58] Express Legacy Endpoint, MSI 00
    Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+

This card is supported in Linux with the open source radeon driver x86-video-ati. The big issue with the EFI firmware of the laptop is that it does not expose the video bios. This is a problem for Linux since the radeon driver does not support UMS anymore and KMS can not find the necessary information so it stalls. This can be worked around by booting with nomodeset which in return will prevent any graphical interface because of the missing UMS support.
The only workaround I have found to be worthwhile and applicable in reality was to patch the kernels radeon driver support to read the video bios from a dump file placed in /lib/firmware/radeon/ and compile myself. Actually somewhere it's mentioned to dump int10.bin as well but the function from the patch actually doesn't include that file? Having the benefit of being able to include extended kernel support for apple hardware built in, the resulting kernel works as expected with a lot of functionality out of the box (like keyboard backlight control e.g.).

The catch

/sys/class/backlight doesn't get populated. It stays empty rendering the function keys for screen brightness control useless. I suppose this has to do with the video bios being read from a dump file but that's just a guess.

I tried to set the brightness directly with

# setpci -s PCI-ID F4.B=value

which does nothing. I tried to boot with every parameter of acpi_backlight where vendor, radeon and native would do nothing and none would render the screen black after starting xorg (I guess that was to be expected but it still surprised me as it seems to affect something where the other parameters didn't).
I also tried to boot with video.only_lcd=0 without any change either. I should probably mention that I use runit instead of systemd but from what I see/read it should not make any difference. The problem, to me it appears, lies in the hand over of the outdated EFI.

I read in the arch wiki that lightum takes brightness levels of screen and keyboard from /sys/devices/platform/applesmc.768/light but doing cat on it gives different numbers completely ignoring the keyboard backlight level during a few minutes. For example: (11,193), (9,161), (1,14) and (2,50) within a few minutes of time.
I even extracted an EDID dump and load it with drm.edid_firmware=, which doesn't help the issue either though.

One interesting find is that /sys/firmware/efi/efivars contains a file called backlight-level-UUID which seems to contain a value. I did cat on it and it returns a questionmark sign.

Booting from a Linux live CD in CSM BIOS mode does populate /sys/class/backlight with a symlink to /sys/devices/virtual/backlight/apple_backlight. This directory contains a file called brightness which can successfully change the brightness of the screen using for example printf value > brightness. This works only in CSM BIOS mode though.

Do you think there's a workaround for this? I am open to further kernel patches. I have read about a physical mode patch but it's very old and outdated. Some of the files that need to be altered don't even exist anymore. Apparently I would prefer not to recompile though.

Last edited by marian (2018-07-17 00:33:18)

Offline

Board footer

Powered by FluxBB