[ltp] CALL FOR TESTING: thinkpad-acpi BETA release 0.14-20070708

[Nathaniel Smith]

On Sun, Jul 08, 2007 at 01:07:24AM -0300, Henrique de Moraes Holschuh wrote:
> HOW AND WHAT TO TEST:
> 
> 	You should test the brightness and volume hot keys, and also
> 	brightness control through the procfs or sysfs interfaces.

Lenovo X60 (BIOS version: 2.08 7BETC7WW 2007-03-07, EC version: 1.10)
Running in 64-bit mode
2.6.22.1 (kernel.org) + thinkpad-acpi-BETA-20070708_2.6.22 patch
X.org 2.1.0, Intel driver (from Debian)
Hal 0.5.9.1 (from Debian)

All three volume keys appear to work perfectly -- they control the
volume in both console and Gnome, and in Gnome they reliably trigger
the volume OSD, the sliders in the alsa mixer magically move up and
down, etc.  This never worked before (the keys affected the volume,
but there was no feedback, so e.g. if one brushed the mute button
accidentally then sound would just mysteriously stop working...)

For me, the brightness keys work in Gnome if and only if I do *not*
have the video module loaded.  (They work either way on the console.)
I restarted X in between each test, here, other strange things happen
if I load/unload video.ko while X is running, but those aren't what
I'm reporting.
  When video.ko is *unloaded*, in Gnome, brightness up/down:
    -- trigger HAL ButtonPressed events
    -- trigger ACPI hotkey events
    -- trigger the OSD, which accurately reflects brightness
    -- actually change the screen brightness
  When video.ko is *loaded*, in Gnome, brightness up/down:
    -- trigger HAL ButtonPressed events
    -- trigger ACPI hotkey events
    -- trigger ACPI LCD events
    -- trigger the OSD, which shows the brightness bar going up and
       down as I press the up/down buttons
    -- however, screen brightness does not change.
  In this last case, there is sometimes a flicker, as if the screen
  brightness *was* being changed, but then immediately being changed
  back again.
If I do the same test at the GDM login screen (i.e., X running, but
Gnome desktop environment not running), then I get no OSD (for obvious
reasons); more interestingly, I then get no change in screen
nbrightness in *either* case -- except that when video.ko is loaded,
Pressing the buttons quickly does sometimes cause a "flicker", and I
cannot get a "flicker" at all when video.ko is not loaded.

None of the above seems to be changed at all if I boot with
brightness_mode=3.

This HAL does have 'laptop_panel.brightness_in_hardware = true' in its
configuration, so in theory *it* shouldn't be messing around with the
brightness...

I also notice there is a very perceptible lag between brightness
button presses and their affect (events showing up in lshal
-m/acpi_listen, the actual brightness changing).  I believe that in
the old version, brightness changes took effect instantaneously, at
least when I was at the console?  It's usable the way it is now, but
it'd be nicer if it were snappier.  (The volume buttons are seen and
take effect immediately.)

I also looked at /proc and /sys entries for the backlight.  Everything
I was able to observe behaved identically whether or not I had
brightness_level=2 or =3, and whether or not video.ko was loaded
(except, of course, that the video.ko-specific files only existed when
it was loaded).

Echoing to /proc/acpi/video/VID/LCD0/brightness works, so long as what
I echo is exactly one of "30", "40", "50", "60", "70", "80", "90",
"100". This works in both console and Gnome, and in Gnome causes the
OSD to pop up.  (Though, the OSD would seem to imply that the
brightness can go lower than it actually can, presumably because it is
drawing it as being at 30% when it is at its minimum.)  Every time I
send one of these numbers to the file, HAL generates exactly one
ButtonPressed event -- even if the brightness changes by more than one
step, or even if it changes by no steps (if I set it to the value that
it already has).  Similarly, /proc/acpi/ibm/brightness displays the
correct brightness, and 'up', 'down', and 'level <n>' commands all
work.  HAL shows a keyboard event, and the Gnome OSD displays
(mysteriously, with the correct 0), whenever I use 'up', 'down', or
use the 'level command to switch the level up or down by exactly one;
if I switch by more than that at once then the screen brightness does
change, but HAL only occasionally reports there being a ButtonPressed
event and I only occasionally get an OSD.  I never get an event if I
set the level to be identical to what it already is.

Everything I said about /proc/acpi/video/VID/LCD0/brightness also
applies to /sys/class/backlight/acpi_video0/brightness, and everything
I said about /proc/acpi/ibm/brightness also applies to
/sys/class/backlight/thinkpad_screen.

Other buttons (all according to lshal -m):
  Fn alone generates wake-up
  Fn-PgUp generates f19, and also toggles the light
  Fn-Space generates f22
  Fn-<arrows> generate appropriate things, and back/forward likewise
  I am not getting any events for Fn-f<anything>, including, Fn-f4 is
    not causing suspend to happen, which it used to -- however, this
    was always somewhat flaky, and I haven't tested it enough to know
    whether it is actually broken now, or just continuing to be flaky.
    (The suspend process itself continues to work like a charm, when
    activated via other means.)
  ThinkVantage generates prog1

So in practice, if I run without video.ko, then everything I care
about works, except for the annoying lag.

Hope this helps,
-- Nathaniel

-- 
In mathematics, it's not enough to read the words
you have to hear the music