On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > this code should actually set the ACPI_VIDEO_BACKLIGHT flag: > drivers/acpi/scan.c: > > static acpi_status > acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, > void **return_value) > { > long *cap = context; > > if (acpi_has_method(handle, "_BCM") && > acpi_has_method(handle, "_BCL")) { > acpi_handle_debug(handle, "Found generic backlight support\n"); > *cap |= ACPI_VIDEO_BACKLIGHT; > /* We have backlight support, no need to scan further */ > return AE_CTRL_TERMINATE; > } > return 0; > } Ah, yeah, my local tree no longer matches the upstream behaviour because I've hacked the EC firmware to remove the backlight trigger because it had an extremely poor brightness curve and also automatically changed it on AC events - as a result I removed the backlight code from the DSDT and just fell back to the native control. Like I said I'm a long way from the normal setup, but this did previously work. The "right" logic here seems pretty simple: if ACPI backlight control is expected to work, use it. If it isn't, but there's a vendor interface, use it. If there's no vendor interface, use the native interface. The problem you're dealing with is that the knowledge of whether or not there's a vendor interface isn't something the core kernel code knows about. What you're proposing here is effectively for us to expose additional information about whether or not there's a vendor interface in the system firmware, but since we're talking in some cases about hardware that's almost 20 years old, we're not realistically going to get those old machines fixed. So, it feels like there's two choices: 1) Make a default policy decision, but then allow that decision to be altered later on (eg, when a vendor-specific platform driver has been loaded) - you've said this poses additional complexities. 2) Move the knowledge of whether or not there's a vendor interface into the core code. Basically take every platform driver that exposes a vendor interface, and move the detection code into the core. I think any other approach is going to result in machines that previously worked no longer working (and you can't just make the vendor/native split dependent on the Coreboot DMI BIOS string, because there are some Coreboot platforms that implement the vendor interface for compatibility, and you also can't ask all Coreboot users to update their firmware to fix things)