[PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, 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.
>
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, 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.
>
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, 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.
>
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, 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.
>
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Tue, Jun 25, 2013 at 6:08 PM, 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.
>
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
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. Well, after some more time spent on that, we now have a series of 3 patches (different from the $subject one) that we think may be used to address this issue. As far as I can say, it has been tested by multiple people whose systems have those problems and they generally saw improvement. It is not my ideal approach, but it seems to be the least intrusive and/or with the least amount of possible side effects that we can do right now as a general measure (alternatively, we could create a possibly long blacklist table of affected systems with different workarounds for them, but let's just say that is not overwhelmingly attractive). [1/3] Make ACPICA export things that we need for checking OSI(Win8). [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() even if it is not going to register the backlight interface (needed for Thinkpads). [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes we are Windows 8. Many thanks to everyone involved! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
