EeePC LCD brightness control

[Eric Anholt]

On Sun, 2008-04-20 at 20:43 -0700, Nate Lawson wrote:
> Eric Anholt wrote:
> > On Sun, 2008-04-13 at 06:53 +0900, Akira Funahashi wrote:
> >> Hi,
> >>
> >> I've created a patch to FreeBSD 7.0-RELEASE for ASUS EeePC.
> >> The patch will be applied to /sys/dev/acpi_support/acpi_asus.c,
> >> which enalbes me to control LCD brightness on EeePC through
> >> sysctl and [Fn]+[F3],[F4] key.
> >>
> >> Here is a patch:
> >>   http://celldesigner.org/~funa/acpi_asus.c.diff
> >>
> >> Hope this helps,
> > 
> > We really need to work out how to get these keys reported as input
> > events so that they can be passed through to the desktop and handled in
> > an appropriate manner.  As-is, we end up with poor backlight management
> > because we've got ACPI and the 2D driver (and HAL trying to use one of
> > the two) fighting over who controls it.
> 
> I'm happy if someone examines how linux dbus does it and comes up with a 
> design.  These drivers can be converted wholesale once we have a plan.
> 
> I don't agree if the plan is to just hack some hardcoded values into 
> kbd(4), on the other hand.

With evdev and a new enough linux kernel, the brightness control keys
get reported as keypresses on an input device.  The X Server picks those
up and reports them as X input events.  Your desktop environment then
pops up its little display as it chooses, and controls the backlight
using RandR properties.  That desktop's job is unimplemented at the
moment, as we just got the first half working not too long ago, and it's
still trickling down to distributions.  Still, the amount of emphasis
that IHVs have been putting on the brightness and display switch keys
means I expect it to be sorted out pretty soon.  I know a GNOME display
switcher is getting written currently.

The particular implementation of the acpi-evdev bits in the kernel are
that it shows up as a separate input device.  That's not a key feature,
but the X Server handles multiple input devices a lot better these days,
so either way we decided to implement it, it should work.

dbus isn't involved, unless the desktop environment chooses to use it
in its implementation of responding to the key event.

I know a lot of people care about these keys working on the console, and
probably more for FreeBSD than Linux.  If we have to have some sort of
latching where the X Server says "no, give key events and control of
brightness", I guess that works, unpleasant though I find it to be.
(Once we get to kernel modesetting, we could have syscons mashing the
output's brightness property on that input event when it was active, so
that could just be a short-term hack anyway).

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080423/0c669aa0/attachment.pgp