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. -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
