Bug 369535

Magnus: can you run xev and press one of the volume keys? It's quite possible that you're in the same situation as me and you only get ACPI events when you press the keys...

I get nothing when pressing volume up/down/mute. I also get nothing when pressing Fn+Up/Down (for screen brightness).

Are the keys bound in the keybindings capplet? I've seen upstream several problems of keybindings getting lost, so that might be the cause.

Volume mute: 0xa0
Volume down: 0xae
Volume up: 0xb0

If I click to create a new accelerator and then hit Volume Up/Down/Mute nothing happens.

Running 'sleep 1; showkey -s' (as root) should show some key events.  Otherwise thinkpad-acpi is broken.

So I checked and thinkpad_acpi was loaded.

Then I run;

sleep 1; showkey -s

as root.

Still nothing. Pressing the FN key by itself does generate a keypress. Not sure if it's important to know.

Timo, so does this look a broken thinkpad-acpi thing as you say?

Yes.

Thomas, do you know whether we already have a bug for tracking this issue?

I have the same problem on an asus laptop too :-) Should I file another bug? Against what?

Vincent, make sure that the asus-laptop is supposed to trigger the events.

You can do so by:

$ cat /proc/bus/input/devices

Identify the input device of the asus-laptop module.

Run (replace X with the device number discovered in the previous step):

$ evtest /dev/input/eventX

This will list the available event codes of the asus-laptop driver.

Make sure that something like this is included:

  (...)
  Event code 224 (Brightness down)
  Event code 225 (Brightness up)
  (...)

If this is the case and showkey -s doesn't report anything, then there's also something fishy about asus-laptop ;-)

An Asus and an old ThinkPad are affected?
I expect the latest 11.0 hit an EC bug which is already addressed mainline.
IMO the best is just to wait, try the next kernel/Alpha and get active if really the next release also shows this regression.

Timo: I don't have those lines with evtest. If I add a special acpid rule to print all events to a file, I can see the that those keys cause acpi events to be fired, though. It'd be possible to have a program listen for those events and use the XTest extension to emit the key event. Or maybe something can be done in asus-laptop (no idea about this).

Thomas: Magnus has a Thinkpad T43P. I can also see the problem on a Thinkpad T60P. And on an Asus M6Ne (but in this case, we can't blame thinkpad-laptop).

This is still an issue with latest Factory (Kernel 2.6.25-19-pae)

Thomas, from comment#11 I get the feeling that you suggest that this is a kernel bug. Please advise.

*** Bug 340818 has been marked as a duplicate of this bug. ***

Thomas, I installed STABLE on a T60 and everything works fine.  Thus I guess that GNOME is out of the line of fire.  Probably an issue of thinkpad_acpi which only affects T4x?

Timo - are you missing the 'p' (for problems) in 'T60p' ? :-)
My current bad-ness in this area, is (I suspect) related to some strange radeonhd interaction with <insert-other-piece-of-system> ;-)

Thomas, *ping*

I have this issue on a T60p, latest Factory from today.  xev and showkeys do not show any key events for volume up/down/mute.  The thinkpad_acpi module is loaded.

For newer ThinkPads [TXZR]{60,61} please make sure you have the latest BIOS.

Please add acpidump output (for latest ThinkPad users, after the BIOS got updated) and state what kind of machine it is in the description.

Created attachment 216371 [details]
acpidump output on T60p with BIOS 2.21

Created attachment 216392 [details]
T42p acpidump

Created attachment 216499 [details]
t60p - latest bios

Interestingly; I get an OSD for brightness - which is nice: but no actual change in brightness [radonehd] ;-) OTOH - I get no OSD for volume changes.

I can confirm I do get an OSD for brightness along with brightness changes (I am using fglrx)

I get brightness changes but no OSD.

This is a nice example why we need a unified interface exported to graphics drivers for brightness changes.

For people where brightness does not change, it may help to pass:
osi="!Windows 2006" boot param, hmm or better brightness_enable=1 as thinkpad_acpi module paramter. Does this work for you Michael?

Egbert, please have a short look at comment #23-#25, JFYI...

Please give me some time and be prepared to test one or the other kernel, I have something in my mind, but my queue is already filled up...

I did modprobe -r thinkpad_acpi ; modprobe thinkpad_acpi brightness_enable=1
Still no brightness joy :-) - I think this is a radeonhd feature-not-bug though it has rather an impact on battery life sadly.

For brightness joy please try 'xbacklight'.

Possible a known limitation of radeonhd:

from
http://www.x.org/wiki/radeonhd#head-d0cfd39d1b149a43f0c1d862f21f4b3ddcb43ae2

"Panel brightness cannot be changed because ACPI events aren't handled properly. Workaround: Switch to a different virtual terminal for that. Affects backlight on a number of laptops, e.g. from the IBM/Lenovo ThinkPad series. (Seems to be fixed in git since some time in 2008-03, needs to be verified)"

My hp Conpaq 8510p has Radeon Mobility HD 2600 and no brightness contol, even when I disable the environmental sensor in the BIOS.

BTW, after running OpenSUSE 11.0 b3 once, brightness control also failed in Windows XP on the same machine.

Current brightnes control is a nightmare...

There also is:
   [Bug 9995] 2.6.25-rc1 regression - backlight controlls do not work -
              ThinkPad T61
   http://bugzilla.kernel.org/show_bug.cgi?id=9995

They introduced a bug (brightness is controlled via Nvidia ACPI device using Software Interrupt instead of the Intel ACPI graphics card device), therefore it works by luck.

This is all a huge mess currently and is very BIOS, graphics card and graphics driver specific... I doubt we can do much for 11.0, but need to work on this in time for 11.1/SLE11.

> BTW, after running OpenSUSE 11.0 b3 once, brightness control also failed in
> Windows XP on the same machine.
Have you done a BIOS update? There were new ACPI BIOS brightness functions introduced for Vista.

(In reply to comment #30 from Thomas Renninger)

> > BTW, after running OpenSUSE 11.0 b3 once, brightness control also failed in
> > Windows XP on the same machine.
> Have you done a BIOS update? There were new ACPI BIOS brightness functions
> introduced for Vista.

No. 
System Information says:
BIOS-Version/-Datum	Hewlett-Packard 68MVD Ver. F.0F, 05.02.2008

And I am running WinXP SP3 here, not Vista.

Thomas, once again we hit the mysterious hotkey mask.  I've asked James and JP to check whether

 $ echo 0xffffffff > /proc/acpi/ibm/hotkey

help.  And, of course, it does.  It seems that thinkpad_acpi doesn't take the hotkey mask as parameter any longer.  I'll see how we deal with that.

For the record:  James now gets the volume events (OSD shows up), JP gets brightness events (but still no events for volume changes).

(In reply to comment #32 from Timo Hoenig)
> Thomas, once again we hit the mysterious hotkey mask.

Not sure if this is applicable or not, but /etc/modprobe.d/thinkpad_acpi does not contain any mask params for me.  So maybe it does take the mask as a param still, but we just aren't passing it?  "options thinkpad_acpi experimental=1" is all I have there.

(In reply to comment #33 from James Willcox)

> Not sure if this is applicable or not, but /etc/modprobe.d/thinkpad_acpi does
> not contain any mask params for me. 

Correct.  It used to ship with a parameter (hotkey_mask=0xsomething) or such.

> So maybe it does take the mask as a param
> still, but we just aren't passing it?  "options thinkpad_acpi experimental=1"
> is all I have there.

Right.  According to 'modinfo thinkpad-acpi' it does no longer give the possibility for passing a parameter.  At least if I'm not mistaken.

(In reply to comment #34 from Timo Hoenig)
> Right.  According to 'modinfo thinkpad-acpi' it does no longer give the
> possibility for passing a parameter.  At least if I'm not mistaken.

I tried the following:

1) echo 0x000000 > /proc/acpi/ibm/hotkey
2) confirm hotkeys are not responding
3) rmmod thinkpad_acpi
4) set /etc/modprobe.d/thinkpad_acpi to "options thinkpad_acpi hotkey=enable,0xffffff experimental=1"
5) modprobe thinkpad_acpi

Hot keys worked fine after that.  Except, of course, the power button.

Alright, that sounds good.  So I will re-add 'hotkey=enable,0xffffff' for now.  Thomas, please speak up if this clashes with something else.  At that point it is likely that I have already submitted a fixed package of acpid to STABLE ;-)

http://www.thinkwiki.org/wiki/Thinkpad-acpi#Hotkeys

It says there that thinkpad-acpi is supposed to Just Work without specifying a mask, but that is obviously not happening.  Perhaps that is why the mask param was removed, I dunno.

Also interesting from dmesg:

thinkpad_acpi: requested hot key mask 0xffffffff, but firmware forced it to 0x00ffffff

Could that possibly cause the power button issue?

Bernhard/Egbert - I'm using HEAD radeonhd driver vs. factory's xserver - and brightness controls still don't work; and xbacklight doesn't appear to want to do much for me either.

I don't think so.  By the way, I've used 0xffffff as default now.  That's what we've been using before we dropped the mask.

I can remember a statement that the driver normally gets things done correctly and that this mask should not be touched by default. I try to get Henrique's attention on this.
James, there are several totally different T60p out there, but you also might want to have a look at this probably unrelated bug: bug #392683, the BIOS version seem to be the same...

(In reply to comment #42 from Thomas Renninger)
> I can remember a statement that the driver normally gets things done correctly
> and that this mask should not be touched by default. I try to get Henrique's
> attention on this.
> James, there are several totally different T60p out there, but you also might
> want to have a look at this probably unrelated bug: bug #392683, the BIOS
> version seem to be the same...
> 

Actually I filed that one :)

Ooops, snorp looks so much different than James Willcox :)

Michael, then you are one of the people who own a laptop that doesn't use the backlight control mechanism of the radeonhd chipset. For this I need to implement the atombios method first.
Currently BIOS controlled backlight support is disabled. We don't want the BIOS to interfer with the chipset driver.

Moving to Thomas, clearly not a GNOME/OSD issue, but much lower level

*** Bug 396594 has been marked as a duplicate of this bug. ***

same issue about volume on X60. was working on 10.3

*sigh*

There are some thinkpad_acpi bugreports but I guess this one matches my issue best:
11.0 final / Gnome / T43
- Brightness settings work with actually changing brightness and OSD
- volume settings work without OSD and without changing the Gnome mixer volume
  (showkeys doesn't show anything for the volume controls but for the Fn 
  brightness keys)

This should work in 11.1. You may want to give factory (latest build) or the next 11.1 BetaX a try.
If you still should have problems in 11.1, pls reopen.
This won't be fixed for 11.0

Weelll ... I have problems in 11.1 - on my T60p.
OTOH - life is a lot better than 11.0 - my brightness setting works well with RadeonHD, and similarly Volume works nicely.

Interestingly - I get an OSD for increasing the brightness [though it gets the brightness level wrong in the bar graph ;-], but not for decreasing the brightness ;-) and I get no volume change display.

Running xev I see Keyboard (or X) events for all the key-presses though.

(In reply to comment #51 from Michael Meeks)


> Interestingly - I get an OSD for increasing the brightness [though it gets the
> brightness level wrong in the bar graph ;-], but not for decreasing the
> brightness ;-) and I get no volume change display.

Regarding OSD for volume:  Please have a look at bug #433553 (e.g. reassigning the keys in gnome-keybindings-properties should help).

> Running xev I see Keyboard (or X) events for all the key-presses though.

Reassigning as this sounds like a GNOME issue. 

I have no further issues in 11.1 on T42p.

Michael, would you mind giving it a try with a new user?  (c.f. bug #407762)

Michael, Ping...

So with 11.1 final - I get on-screen displays for volume (which works) and also brightness - which shows an incorrect level - switching to a clean / demo user - I have the same problem.

The OSD display shows up - but the progress bar is 100% regardless of the level of brightness set by the keys (which do function as expected).

The version with which you had the bug is now obsolete. I'll close this as NORESPONSE. If you can still reproduce it in current 11.4, please reopen the bug and move it to the appropriate version. Thanks!