On dim., 2013-06-09 at 19:01 -0400, Matthew Garrett wrote: > The first two patches in this series are picked from other patchesets aimed at > solving similar problems. The last simply unregisters ACPI backlight control > on Windows 8 systems when using an Intel GPU. Similar code could be added to > other drivers, but I'm reluctant to do so without further investigation as > to the behaviour of the vendor drivers under Windows. Hi, I've read this thread coming from https://bugzilla.kernel.org/show_bug.cgi?id=51231 and tried the patches on a Lenovo ThinkPad X230 with intel graphics. The problem with thoses fixes is that they still introduce a regression in how the brightness is handled, at least for me. Before Linux support for acpi_osi("Windows 2012") (and when booting with acpi_osi="!Windows 2012"), brightness keys were handled by the kernel just fine, whether in console, in the display manager or in my desktop environment (Xfce). xfce4-power-manager just needs to be told that the brightness keys are already handled and it doesn't need to do anything. After Linux started responding to Win8 ACPI checks, it somehow broke, but not completely. Brightness keys are not handled by the kernel anymore (so no brightness adjustment in console or without a hotkey daemon running). If I run xfce4-power-manager and tell it to handle the brightness keys, it does work (although the number of brightness levels is not completely right). That means both acpi_video0 and intel_backlight backlight interfaces work, they just don't have the same precision and max_brightness (more details on the bug). When adding those three patches, well, acpi_video0 is removed (as intended), but I still don't have brightness handling in the kernel and need to have something handling it in userspace. I really think this is a bad idea. In some cases it might be the only solution, but having a place where this is set consistently would be really best, imho. Every userspace daemon might do things differently, and not everyone even has it. And I'm really not sure brightness keys should be handled by a desktop environment anyway. So can the previous behavior be actually restored? Maybe it was easier to pass the brightness keys information from thinkpad_acpi.ko to video.ko than it is to i915.ko but since it goes to the input layer anyway I guess it could be fed to module handling that in a way or another? Please keep me on CC: on replies, I'm not subscribed to the various lists. Regards, -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part
