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

[Sebastian Schmidt]

Hi Henrique,

I tested a bit. Notebook is Lenovo X60s, BIOS version is 2.07
(7BETC6WW) as of 2007-02-06.

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.

Brightness buttons work and generate the following ACPI events:
* Down:
  ibm/hotkey HKEY 00000080 00005010
  video LCD0 00000087 00000000

* Up:
  ibm/hotkey HKEY 00000080 00005010
  video LCD0 00000086 00000000

However, each time pressing a brightness key brings up the following:
  thinkpad_acpi: unknown LID-related hotkey event: 0x5010
  set_level status: 0

When pressing a button, the display has a "lag" of about 1.5 seconds for
the brightness to get applied. Also, setting brightness via /proc
doesn't work:
  echo: write error: invalid argument
with 0 to 7. Same result with brightness_mode=3 (but more on that
below). Nothing in dmesg.


>   You should test it with and without the ACPI video module loaded.
>   start the test with the ACPI video module *loaded*, and only if
>   something weird happens, unload it.

Did so, but then the keys stop working (not even an ACPI event gets
triggered). Setting the brightness via /proc still doesn't work.

>   I am not sure about the volume hot keys.  Nobody reported how they
>   are behaving on the *60 and *61 machines yet directly to me, but I
>   have seen some mentions of only mute working.  They might need the
>   same fix that was done to brightness.  Please check that.

Work here, but only after echo 0xffffffff > /proc/apci/ibm/hotkey:
* Mute:        ibm/hotkey HKEY 00000080 00001017
* Volume down: ibm/hotkey HKEY 00000080 00001016
* Volume up:   ibm/hotkey HKEY 00000080 00001015

The blue "ThinkVantage" key however doesn't even work with 0xffffffff.

> Other data:
>   thinkpad-acpi will select "brightness_mode=2" for lenovo thinkpads,
>   and "brightness_mode=3" for IBM thinkpads.  If things are not
>   working, try messing with that parameter and report back if it fixes
>   things.

After I noticed brightness isn't working, I tried reloading
thinkpad_acpi with brightness_mode=3 and got the following from
modprobe:
  FATAL: Error inserting thinkpad_acpi
    (/lib/modules/.../misc/thinkpad_acpi.ko): Input/output error

Strange enough, the module *got* loaded:
  Non-volatile memory driver v1.2
  thinkpad_acpi: ThinkPad ACPI Extras v0.14
  thinkpad_acpi: http://ibm-acpi.sf.net/
  thinkpad_acpi: ThinkPad BIOS 7BETC6WW (2.07 ), EC 7BHT37WW-1.10
  thinkpad_acpi: Lenovo ThinkPad X60s
  thinkpad_acpi: radio switch found; radios are enabled
  thinkpad_acpi: CMOS NVRAM (7) and EC (0) do not agree on display
  brightness level
  thinkpad_acpi: ThinkPad ACPI Extras v0.14
  thinkpad_acpi: http://ibm-acpi.sf.net/
  thinkpad_acpi: ThinkPad BIOS 7BETC6WW (2.07 ), EC 7BHT37WW-1.10
  thinkpad_acpi: Lenovo ThinkPad X60s
  thinkpad_acpi: radio switch found; radios are enabled
  input: ThinkPad Extra Buttons as /class/input/input8

(Yes, the "thinkpad_acpi: ThinkPad ACPI Extras v0.14" line and the
following ones *were* displayed twice.)

FYI, the first modprobe:
  thinkpad_acpi: ThinkPad ACPI Extras v0.14
  thinkpad_acpi: http://ibm-acpi.sf.net/
  thinkpad_acpi: ThinkPad BIOS 7BETC6WW (2.07 ), EC 7BHT37WW-1.10
  thinkpad_acpi: Lenovo ThinkPad X60s
  thinkpad_acpi: radio switch found; radios are enabled
  input: ThinkPad Extra Buttons as /class/input/input7

What makes me wonder a bit is the last line of each paste. The first
time the driver gets registered as input7, the second time as input8. Is
this a bug (not unregistering the driver), or doesn't the kernel
allocate an input device node twice?

I've also seen something else a couple of times in the syslog, however I
cannot tell you when exactly this was showing up:
  thinkpad_acpi: unknown LID-related hotkey event: 0x5010
  set_level status: 0

I don't know if that might be helpful, but right after booting the
following showed up in dmesg:
  ACPI Warning (tbfadt-0434): Optional field "Gpe1Block" has zero address
  or length: 000000000000102C/0 [20070126]
(If you want the complete dmesg output, just ask - but I didn't want to
paste things here that are unlikely to be helpful (in my layman's eyes,
of course :-)).

>   The kernel ACPI video module reacts to the ACPI brightness change
>   events, and the new BIOSes apparently do produce those instead of
>   changing the brightness directly in firmware. So, the presence of
>   this module may be a key factor on brightness keys working, and I
>   need to know about this for sure.

Ah, that explains my above observation.

>   tpb, thinkpad-keys and HAL often react to brightness UP/DOWN as
>   well, and so they might skew test results.  Therefore, please test
>   in a console with these things unloaded first, and then test with
>   whatever your normal desktop environment is.

Uhm, I don't run a desktop environment so neither hal, tpb or anything
else got loaded. This shouldn't make any difference, should it? (I
tried, however, setting the brightness via /proc on a framebuffer
console, just to be sure.)

> Thank you for your help.

Thank you for your work. ;-)


Greetings,
  Sebastian