Created attachment 274689 [details] acpidump The /sys/class/backlight (drivers/video/backlight/apple_bl.c) functionality on my Apple "MacBook2,1" no longer works. It did work before my harddrive crashed but I no longer have those kernel .config files, but I'm beginning to think the problem might not be with my configuration. A notable difference with the way I'm running the laptop now is that I no longer boot "normally" off an internal sata harddrive, but rather using the alternative method (pressing the on button while holding down the Alt key) which allows me to boot off a usb stick -- which, I think (not sure), involves a lot more EFI stuff. I tried testing with kernels ranging from the most recent stable 4.15.7, 4.10, 4.8 and 4.7, and all basically behave the same way -- an empty /sys/class/backlight directory, and no errors in dmesg, nor when I load apple_bl as a module. I tried playing with various kernel command line parameters, like acpi_backlight=vendor|video|native, video.use_native_backlight=1, acpi_osi=, etc, with no effect. Lukas Wunner noticed that apple_bl.c "only binds to ACPI device APP0002." He asked me to check if I have that device but I'm not sure how to check. acpidump doesn't mention it, but I had this working before soooo surely I must. He also asked me to include the kernel parameter "dump_apple_properties" to see which properties are supplied on older machines, but I don't think that added anything to my dmesg. I'm not sure if I need to change some other kernel CONFIG option to get it to output: "I'm curious which properties are supplied on older machines and if this works at all because this might even be an EFI mixed-mode machine depending on if this is the Late 2006 or Mid 2007 version. The former used mixed-mode (64 bit CPU but 32 bit EFI) and noone ever tested whether the code to retrieve Apple EFI properties works in mixed-mode." It is indeed one of those annoying mixed-mode machines, 64bit cpu, 32bit efi. I've attached the outputs to acpidump, dmesg, and lspci -vvvv -xxxx. # find /sys | grep -i backl /sys/class/backlight /sys/bus/acpi/drivers/Apple backlight /sys/bus/acpi/drivers/Apple backlight/bind /sys/bus/acpi/drivers/Apple backlight/unbind /sys/bus/acpi/drivers/Apple backlight/uevent /sys/module/video/parameters/disable_backlight_sysfs_if # cat /sys/module/video/parameters/disable_backlight_sysfs_if -1 # find /sys | grep -i apple | grep -v applesmc | grep -v /sys/firmware/efi /sys/bus/hid/drivers/apple /sys/bus/hid/drivers/apple/bind /sys/bus/hid/drivers/apple/0003:05AC:021A.0001 /sys/bus/hid/drivers/apple/unbind /sys/bus/hid/drivers/apple/module /sys/bus/hid/drivers/apple/0003:05AC:021A.0002 /sys/bus/hid/drivers/apple/uevent /sys/bus/hid/drivers/apple/new_id /sys/bus/acpi/drivers/Apple backlight /sys/bus/acpi/drivers/Apple backlight/bind /sys/bus/acpi/drivers/Apple backlight/unbind /sys/bus/acpi/drivers/Apple backlight/uevent /sys/module/apple_bl /sys/module/apple_bl/parameters /sys/module/apple_bl/parameters/debug /sys/module/apple_bl/uevent /sys/module/hid_apple /sys/module/hid_apple/parameters /sys/module/hid_apple/parameters/ejectcd_as_delete /sys/module/hid_apple/parameters/iso_layout /sys/module/hid_apple/parameters/rightalt_as_rightctrl /sys/module/hid_apple/parameters/swap_opt_cmd /sys/module/hid_apple/parameters/fnmode /sys/module/hid_apple/parameters/swap_fn_leftctrl /sys/module/hid_apple/uevent /sys/module/hid_apple/drivers /sys/module/hid_apple/drivers/hid:apple # cat .config | grep APPLE | grep -v ^# CONFIG_SENSORS_APPLESMC=y CONFIG_BACKLIGHT_APPLE=y CONFIG_HID_APPLE=y CONFIG_APPLE_GMUX=m CONFIG_APPLE_PROPERTIES=y # cat .config | grep BACKLIGHT | grep -v ^# CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_APPLE=y # cat .config | grep FB | grep -v ^# CONFIG_FB=y CONFIG_FB_CMDLINE=y CONFIG_FB_NOTIFY=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_EFI=y # cat .config| grep EFI | grep -v ^# CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI_MIXED=y CONFIG_FB_EFI=y CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_EFI_VARS=y CONFIG_EFI_ESRT=y CONFIG_EFI_RUNTIME_MAP=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_EFI_DEV_PATH_PARSER=y CONFIG_EFIVAR_FS=y CONFIG_EARLY_PRINTK_EFI=y
Created attachment 274691 [details] lspci
Created attachment 274693 [details] dmesg
Hi Dennis, the acpidump needs to be extracted (acpixtract -a) and disassembled (iasl -d), but it does show the APP0002 device: Device (PNLF) { Name (_HID, EisaId ("APP0002")) // _HID: Hardware ID Name (_CID, "backlight") // _CID: Compatible ID Name (_UID, 0x0A) // _UID: Unique ID Name (_STA, 0x0B) // _STA: Status } Looking at apple_bl.c, it tests access to the backlight on probe: /* Check that the hardware responds - this may not work under EFI */ intensity = hw_data->backlight_ops.get_brightness(NULL); if (!intensity) { hw_data->set_brightness(1); if (!hw_data->backlight_ops.get_brightness(NULL)) return -ENODEV; hw_data->set_brightness(0); } Note the code comment, it looks like your suspicion was correct that the boot method makes a difference here. You've booted with apple_bl.debug=1 but that may not show anything unless you also enable logging of debug level messages. Try booting with "apple_bl.dyndbg=+p" or reload the module with "rmmod apple_bl ; modprobe apple_bl dyndbg=+p" (see Documentation/admin-guide/dynamic-debug-howto.rst). That should result in a message from intel_chipset_get_intensity() showing what was read. The commit that introduced the above code mentions: "The SMI-based backlight control functionality may fail to work if the system is running under EFI rather than BIOS." There's no explanation why. :-( http://git.kernel.org/linus/99fd28e19429 I guess the driver is using a feature that's only meant to be used by Windows (BootCamp), so is only available when booting in CSM mode. Surely there must be a way to control the backlight when booting in EFI mode, otherwise it wouldn't work under macOS. But I've no idea what that could be. Understanding this would involve disassembling and digging into AppleBacklight.kext and AppleBacklightExpert.kext. By the way, are you using a 32-bit or 64-bit kernel? What does /usr/bin/arch say? The dump_apple_properties parameter did not have any effect. It only works if the kernel is started via the efistub. If you're using grub I think by default it doesn't use the efistub, but systemd-boot, rEFIt etc. would. In the meantime it's occurred to me that Matt Fleming once told me that booting in mixed mode via the efistub does not work yet: https://lkml.org/lkml/2016/8/24/645 So I think booting a 32-bit kernel via the efistub might work, but booting a 64-bit kernel might not.
With apple_bl.dyndbg=+p I get: [ 12.193711] apple_bl: read brightness of 0 [ 12.194146] apple_bl: read brightness of 0 I'm using a 64-bit kernel, x86_64.
(In reply to Dennis from comment #4) > With apple_bl.dyndbg=+p I get: > [ 12.193711] apple_bl: read brightness of 0 > [ 12.194146] apple_bl: read brightness of 0 Well that's precisely the problem, the backlight is inaccessble for this driver, presumably because the machine was booted in EFI instead of CSM mode. Backlight control is handled by the Intel GPU, looking at the code I notice that there's even a quirk for the MacBook2,1 to enable backlight control in i915: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c#n14276 I don't see any mention of i915 in the dmesg output you've attached. Try loading that module and see if it registers a backlight.
Hmm. Trying to load i915 crashes my system. So I compiled it as a module to be able to see the error messages. Modprobing drm and drm_kms_helper worked okay, it seems. But when trying to modprobe i915, my screen became messed up (wide white horziontal lines), with dmesg saying things like: i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff [drm] Failed to find VBIOS tables (VBT) It also mentioned sometihng about a backlight, so maybe if I get i915 working, I'll have the backlight: [drm] applying backlight present quirk
Created attachment 274821 [details] modprobe i915
To get backlight control working when booting in EFI mode you'll definitely need i915. It must have worked in the past, otherwise the quirk for the MacBook2,1 wouldn't be there. I'm not familiar enough with i915, especially the older chip generations, to help you, but Intel has a large and very active team of developers and supporters who will be able to tell you which command line parameters to add so that the issue can be rootcaused. Unfortunately i915 uses a different bugtracker at https://bugs.freedesktop.org (Product: DRI, Component: DRM/Intel). Could you file a bug there and close this one? Sorry for not telling you right away to file a bug there, I wasn't aware that this is really an i915 issue. It'd probably be best if you include dmesg output of loading i915 with the drm.debug=0xf option so that they get some more debug output right away.
See https://bugs.freedesktop.org/show_bug.cgi?id=105637
i915 crashing MacBook2,1 was fixed in Linux 4.19. The backlight was also reported to be working again. See https://bugs.freedesktop.org/show_bug.cgi?id=105637, which is now CLOSED FIXED. I think this bug here on the kernel bugzilla can be closed now as well.