[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130625160848.GA27123@srcf.ucam.org>
Date: Tue, 25 Jun 2013 17:08:48 +0100
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Yves-Alexis Perez <corsac@...ian.org>
Cc: linux-acpi@...r.kernel.org, seth.forshee@...onical.com,
joeyli.kernel@...il.com, daniel.vetter@...ll.ch,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, lenb@...nel.org, rjw@...k.pl,
Henrique de Moraes Holschuh <hmh@...ian.org>
Subject: 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 | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists