[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).

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