[ltp] QUESTION: HAL support for some T42 keys?

[Henrique de Moraes Holschuh]

On Tue, 22 Sep 2009, Guarded Identity wrote:
> I want a callback for backlight keystrokes so I can persist the current value
> to a file.  This is kind of inspired by a feature I saw in Windows where there
> was different settings depending on whether the AC was plugged in or not.  It's
> more about increased battery life than about inverter life.

Any recent version of the driver should store the backlight in NVRAM using
platform methods, that will be honoured by the BIOS and MS Windows.  This
translates to the ThinkPad always booting (and resuming from sleep) in the
last brightness you had set, regardless of what you used last (BIOS, Linux,
Windows).  This will honour any direct changes you make to the brightness
using sysfs, as well.

This might be screwed up in the latest Lenovo boxes, but I don't think so.
It certainly is supposed to work perfectly on any T4x *if you use the latest
thinkpad-acpi driver*.  The driver picks the wrong brightness mode for
certain thinkpads in 2.6.30 (if it is booting with low brightness, it is
this bug).  I have not been able to get a patch accepted to fix it yet, but
you work around the bug by directly setting the "brightness_mode" parameter
to the proper value for your thinkpad (depends on the kind of GPU you have:
ATI or Intel embedded).

Also, the firmware will change by itself the brightness curve to one that
takes about half the ammount of power when not in AC, unless you disabled
that function in the BIOS.

You are supposed to be able to safely use the brightness up/down keys for
callbacks, as long as you assign to them a keycode that is NOT
brightness_up/down.  But that depends on nothing in userspace doing stupid
things like listening to the deprecated ACPI events and trying to change
brightness when the brightness keys are pressed.

> I'm currently doing this callback with tpb.   One could probably argue that I

Make sure you have the latest T42 BIOS, if you have a very old version, the
driver needs to do NVRAM polling to get data for many of the hotkeys.  The
latest version of the BIOS for the T40-T42 has full support for ACPI events
for all hotkeys, so I don't need to poll the NVRAM.

Polling the NVRAM takes a lot more CPU and power than using ACPI events. tpb
does NVRAM polling, BTW.

> This was going to be halevt.  The brightness setting persistence feature would
> make sense for this daemon since it's not really related to X.

Brightness setting persistence is something handled by the platform on
ThinkPads.  If you need anything in userspace to get that persistence, it
means there is a bug in the driver and I'd be quite happy to hear about it
and get it fixed.

Please test the latest version of thinkpad-acpi, that you can get from
http://ibm-acpi.sf.net (I have announced a new version three days ago on
this ML).

> Then I was going to run another daemon as a child of X (kicked off by Xsession)
> to manage very X-related things like
> 
>     - OSD

OSD for brightness will be done right in 2.6.32, thanks to some base work by
RedHat.  The thinkpad-acpi patches to use the new support are already being
reviewed upstream, and I should publish within this month a new version of
thinkpad-acpi backporting them all.

Basically, the backlight class will have UEVENT and poll() support to detect
brightness changes, so you can do OSD right for any backlight device, in a
generic way.

For volume OSD, the ALSA mixer patch for thinkpad-acpi is what is hot in my
development tree right now, so it should be available for 2.6.33 (or with a
_lot_ of luck, 2.6.32), and *much* earlier than that on ibm-acpi.sf.net test
releases.

Meanwhile, you can abuse the hotkeys to do OSD, but please do it in a way
that does not feedback volume changes or brightness changes to the
thinkpad-acpi driver.  Also, keep in mind that if you let a volume hotkey in
a T4x change volume in the AC97 mixer, it will make for a very crappy
dynamic range in the builtin speakers and headphone output.

> tpb does this fine, but I was okay running another instance of halevt too.

Well, the problem with tpb is 10 wakeups per second and slow reads of the
CMOS NVRAM pestering the CPU :)  That wastes battery life.

> Don't worry about the tone.  No harm done.  I'm happy to talk things through to
> get your take on the issues.

Thanks.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh