On Wed, 2013-07-31 at 02:01 +0200, Rafael J. Wysocki wrote:
On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote:
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
On 07/31/2013 08:01 AM, Rafael J. Wysocki wrote:
On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote:
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
On 07/31/2013 08:01 AM, Rafael J. Wysocki wrote:
> On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote:
>> 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
On Wed, 2013-07-31 at 02:01 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote:
> > 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.
On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote:
> 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
On Wed, 2013-07-31 at 02:01 +0200, Rafael J. Wysocki wrote:
> (3) Fix i915 backlight control issues for all systems known to have them
> (that may take a while) and flip the defailt for that option to set when
> we
> think we're ready.
Unfortunately I don't have any systems that
On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote:
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
On Wed, 2013-07-31 at 02:01 +0200, Rafael J. Wysocki wrote:
(3) Fix i915 backlight control issues for all systems known to have them
(that may take a while) and flip the defailt for that option to set when
we
think we're ready.
Unfortunately I don't have any systems that reproduce
On Wed, Jul 17, 2013 at 7:16 PM, Rafael J. Wysocki wrote:
> 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
On Wed, Jul 17, 2013 at 7:16 PM, Rafael J. Wysocki r...@sisk.pl wrote:
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
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
>
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
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
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez cor...@debian.org wrote:
On dim., 2013-06-09 at 19:01 -0400, Matthew Garrett wrote:
The first two patches in this series are picked from other patchesets aimed
at
solving similar problems. The last simply unregisters ACPI backlight control
On 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
On mer., 2013-07-17 at 10:51 -0500, Felipe Contreras wrote:
On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez cor...@debian.org wrote:
Before Linux support for acpi_osi(Windows 2012) (and when booting with
acpi_osi=!Windows 2012), brightness keys were handled by the kernel
just fine,
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
>
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
On Tue, Jun 25, 2013 at 6:08 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
Before Linux support for acpi_osi(Windows 2012) (and when booting with
acpi_osi=!Windows 2012), brightness keys were handled by the kernel
just fine,
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
48 matches
Mail list logo
