Date: Tue, 22 Apr 2008 17:29:22 -0700 From: Eric Anholt <eric@anholt.net> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: EeePC LCD brightness control Message-ID: <1208910562.5900.25.camel@localhost.localdomain> In-Reply-To: <480C0D5A.2020603@root.org> References: <m2hce668q2.wl%funa@funa.org> <1208294538.8383.10.camel@localhost.localdomain> <480C0D5A.2020603@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-zoID7/VjmahSksj3tPc2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, > >=20 > > 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. >=20 > I'm happy if someone examines how linux dbus does it and comes up with a=20 > design. These drivers can be converted wholesale once we have a plan. >=20 > I don't agree if the plan is to just hack some hardcoded values into=20 > 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. =EF=BB=BFThe 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. =EF=BB=BFdbus 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). --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-zoID7/VjmahSksj3tPc2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgOguIACgkQHUdvYGzw6veZYACff4a6eY/XrXWl+kOxtpOOFTud EKAAn2WbodsHUHw309OHchCj7L+0ugiY =usSO -----END PGP SIGNATURE----- --=-zoID7/VjmahSksj3tPc2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1208910562.5900.25.camel>