On mar., 2013-06-25 at 22:33 +0100, Matthew Garrett wrote:
I was referring to “standardize the behaviour by leaving up to userspace”. A lot of thinkpads (for example) (all the pre-windows 8 ones) have a perfectly working ACPI backlight interface.
And this patchset won't alter their behaviour.
Sorry if I was unclear and if my mail implied that. It was about your remark later in the thread (and the mail from Daniel Vetter)
Also, if the kernel has no way of knowing which levels work, I fail to see how userspace can do better.
It can't. That's why this patchset disables the ACPI interface on Windows 8 systems.
I understand that switching to intel_backlight instead of acpi_video0 follows what Windows 8 recommends but for me it looks orthogonal to the fact ACPI methods now have some awkward (Lenovo) or broken (Dell). I mean, it's not the first time firmware people break some kernel behavior. I know it's usually not easy to contact them, but shouldn't those methods be fixed, instead of somehow blindly switching to graphic drivers?
No. The correct answer to all firmware issues is "Are we making the same firmware calls as the version of Windows that this hardware thinks it's running". If Windows 8 doesn't make these calls, we shouldn't make these calls.
But if that introduce regressions, shouldn't workarounds be found then? Sorry if I keep repeating that but brightness keys handling in-kernel is quite a useful feature and losing it (because of the “behave exactly like Windows 8 kernel” policy) is indeed a regression.