Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez cor...@debian.org wrote: 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. For me too. 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. How do you tell xfce4-power-manager that? For me everything works fine when acpi_osi=!Windows 2012, which is why I wrote a patch for this particular laptop. http://article.gmane.org/gmane.linux.acpi.devel/60969 So can the previous behavior be actually restored? It *should*. The #1 rule of the Linux kernel is to never ever break user-space, isn't it? Please keep me on CC: on replies, I'm not subscribed to the various lists. You don't need to ask that in mailing lists that don't have reply-to munged (sane ones), and vger ones don't. Cheers. -- Felipe Contreras ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On mer., 2013-07-17 at 10:51 -0500, Felipe Contreras wrote: On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez cor...@debian.org wrote: 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. How do you tell xfce4-power-manager that? xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/change-brightness-on-key-events -s false You might have to create the key before. See https://bugzilla.xfce.org/show_bug.cgi?id=7541 for more information. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote: 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. Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. Could this functionality be duplicated across other backlight drivers? Not easily. The ACPI driver receives keypresses and performs backlight control. The i915 driver doesn't receive keypresses. We could easily tie certain keycodes into backlight events, but which backlight should they control? You're really starting to get into the kind of complex policy decision that's best left to userspace, which is where it should have been to begin with. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote: 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. Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. Could this functionality be duplicated across other backlight drivers? Not easily. The ACPI driver receives keypresses and performs backlight control. The i915 driver doesn't receive keypresses. We could easily tie certain keycodes into backlight events, but which backlight should they control? You're really starting to get into the kind of complex policy decision that's best left to userspace, which is where it should have been to begin with. Do we have any chances to amend this mistake by (gradually) phasing out support for the direct keypress forwarding in ACPI? Or at least some plans? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 06:10:35PM +0200, Daniel Vetter wrote: Do we have any chances to amend this mistake by (gradually) phasing out support for the direct keypress forwarding in ACPI? Or at least some plans? We could make the default value of brightness_switch_enabled a config variable and encourage distributions to flip their behaviour. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote: On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote: 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. Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. I'm not sure what that means. To detect what case exactly? That the brightness is handled by video.ko? Could this functionality be duplicated across other backlight drivers? Not easily. The ACPI driver receives keypresses and performs backlight control. The i915 driver doesn't receive keypresses. We could easily tie certain keycodes into backlight events, but which backlight should they control? You're really starting to get into the kind of complex policy decision that's best left to userspace, which is where it should have been to begin with. Well, I get the reasoning, but I'm not sure I agree. That means userspace behavior is inconsistent depending on who does it (gnome-power-manager, gnome-setting-daemon, whatever), and it usually means there's nothing handling the brightness before those are running, not to mention people not running them because they don't run a full blown desktop environment (until someone starts thinking it's a good idea to handle brightness in systemd). And in the end, the user just want the brightness keys to correctly handle the brightness, full stop. Having multiple brightness daemons using different policies on different hardware is a nightmare for the end user, imho. From a user point of view, having it handled all in the kernel works really pretty fine and is completely transparent (I have to admit that from that point of view, it was even better when it was handled by the EC but those times seem long gone). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote: Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. I'm not sure what that means. To detect what case exactly? That the brightness is handled by video.ko? That the kernel will automatically handle backlight key presses. Could this functionality be duplicated across other backlight drivers? Not easily. The ACPI driver receives keypresses and performs backlight control. The i915 driver doesn't receive keypresses. We could easily tie certain keycodes into backlight events, but which backlight should they control? You're really starting to get into the kind of complex policy decision that's best left to userspace, which is where it should have been to begin with. Well, I get the reasoning, but I'm not sure I agree. That means userspace behavior is inconsistent depending on who does it (gnome-power-manager, gnome-setting-daemon, whatever), and it usually means there's nothing handling the brightness before those are running, not to mention people not running them because they don't run a full blown desktop environment (until someone starts thinking it's a good idea to handle brightness in systemd). The behaviour is already inconsistent. If you have an ACPI backlight interface, hitting the keys makes your brightness change without any userspace help. If you don't, it doesn't. And in the end, the user just want the brightness keys to correctly handle the brightness, full stop. Having multiple brightness daemons using different policies on different hardware is a nightmare for the end user, imho. From a user point of view, having it handled all in the kernel works really pretty fine and is completely transparent (I have to admit that from that point of view, it was even better when it was handled by the EC but those times seem long gone). I agree, we should standardise the behaviour. And the only way we can standardise the behaviour is to leave it up to userspace. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote: On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote: Right, the kernel has special-casing to hook the backlight keys up to the ACPI backlight control. This is an awful thing, because there's no way to detect this case other than parsing a single driver-specific module parameter. I'm not sure what that means. To detect what case exactly? That the brightness is handled by video.ko? That the kernel will automatically handle backlight key presses. Ok, so for detection by userspace? hal managed to do that just fine, it seems that upower doesn't, for some reason. The behaviour is already inconsistent. If you have an ACPI backlight interface, hitting the keys makes your brightness change without any userspace help. If you don't, it doesn't. At least on the same (class of) hardware it always behaves the same. And in the end, the user just want the brightness keys to correctly handle the brightness, full stop. Having multiple brightness daemons using different policies on different hardware is a nightmare for the end user, imho. From a user point of view, having it handled all in the kernel works really pretty fine and is completely transparent (I have to admit that from that point of view, it was even better when it was handled by the EC but those times seem long gone). I agree, we should standardise the behaviour. And the only way we can standardise the behaviour is to leave it up to userspace. It's pretty clear we disagree on this and that my opinion won't really matter here. But letting userspace handle that just means broken functionality for those who have the chance (apparently) to have an ACPI backlight interface. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote: I agree, we should standardise the behaviour. And the only way we can standardise the behaviour is to leave it up to userspace. It's pretty clear we disagree on this and that my opinion won't really matter here. But letting userspace handle that just means broken functionality for those who have the chance (apparently) to have an ACPI backlight interface. Which, as we've already established, you don't - Lenovo broke it. Your Thinkpad claims to have 100 available levels, and most of them don't work. The kernel has no way of knowing which levels work and which don't, so leaving this up to the kernel won't actually fix your system either. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote: On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote: I agree, we should standardise the behaviour. And the only way we can standardise the behaviour is to leave it up to userspace. It's pretty clear we disagree on this and that my opinion won't really matter here. But letting userspace handle that just means broken functionality for those who have the chance (apparently) to have an ACPI backlight interface. Which, as we've already established, you don't - Lenovo broke it. Your Thinkpad claims to have 100 available levels, and most of them don't work. The kernel has no way of knowing which levels work and which don't, so leaving this up to the kernel won't actually fix your system either. 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. Also, if the kernel has no way of knowing which levels work, I fail to see how userspace can do better. 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? -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:30:37PM +0200, Yves-Alexis Perez wrote: On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote: Which, as we've already established, you don't - Lenovo broke it. Your Thinkpad claims to have 100 available levels, and most of them don't work. The kernel has no way of knowing which levels work and which don't, so leaving this up to the kernel won't actually fix your system either. 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. 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. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
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 signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 11:46:01PM +0200, Yves-Alexis Perez wrote: 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. Your firmware behaves differently depending on whether the OS claims to be Windows 8 or not. We can't make that invisible. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
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 signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. 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. I've received some feedback from user testing of these patches (don't have an affected machine myself) and the feedback is mostly good. One user reported it didn't work, but I that machine may have discrete graphics (waiting to hear back from the user). The main drawback I see with any approach like this one is that the backlight remains broken for users of proprietary graphics drivers. Seth ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
Hi Matthew, On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. 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. I happen to know that alternative solution to this problem is being worked on, so I'm going to wait until it is submitted and then we'll decide what to merge. I'm slightly concerned about unregistering ACPI backlight control for all systems declaring win8 support, even though it may actually work for them. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Mon, 2013-06-10 at 13:59 +0200, Rafael J. Wysocki wrote: I happen to know that alternative solution to this problem is being worked on, so I'm going to wait until it is submitted and then we'll decide what to merge. Sure. I'm slightly concerned about unregistering ACPI backlight control for all systems declaring win8 support, even though it may actually work for them. Right, that's why I think it's correct to leave it up to the graphics drivers. It seems like they're the ones that make the policy determination under Windows now. The policy as implemented here may not be correct, but doing better would probably involve Intel letting us know how their Windows driver behaves. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
