This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 321421 - thinkpad_acpi events interface has changed
thinkpad_acpi events interface has changed
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened, Triaged
: 444055 (view as bug list)
Depends On:
Blocks: F8Blocker
  Show dependency treegraph
 
Reported: 2007-10-06 12:33 EDT by Luis Villa
Modified: 2014-01-21 17:59 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 00:59:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
screenshot (45.21 KB, image/png)
2007-10-07 17:48 EDT, David Zeuthen
no flags Details
lshal (121.45 KB, text/plain)
2007-10-10 23:23 EDT, Luis Villa
no flags Details

  None (edit)
Description Luis Villa 2007-10-06 12:33:40 EDT
My thinkpad keys don't work out of the box on my thinkpad x41 tablet with F8
test3, nor on my x31. Filing against system-config-keyboard for lack of a better
place- no idea who owns this.

Note that if tpb is installed, the keys work, but with an ugly green thing
straight out of the mid-90s.

These keys have worked out of the box with Ubuntu since some time in 2005, with
a beautiful little gnome-y visualization instead of the ugly green thing.
Combine with the popularity of thinkpads, and hence the 'high' severity.
Comment 1 Martin Jürgens 2007-10-07 10:45:21 EDT
maybe a bug in xkeyboard-config
Comment 2 Bastien Nocera 2007-10-07 11:07:18 EDT
Should be working with the ibm acpi module loaded. Richard?
Comment 3 Luis Villa 2007-10-07 11:33:05 EDT
thinkpad_acpi is loaded on the x41 (haven't checked the x31.) Is that what you
mean for ibm_acpi? There is no ibm_acpi.ko on the F8t3 livecd system. There are:

./drivers/pci/hotplug/ibmphp.ko
./drivers/pci/hotplug/acpiphp_ibm.ko
Comment 4 Stephen 2007-10-07 12:24:33 EDT
Fixing this should close this f7 tpb bug too:

  https://bugzilla.redhat.com/show_bug.cgi?id=248879

(haven't checked f8 myself yet, sorry)
Comment 5 Seth Vidal 2007-10-07 14:04:08 EDT
Luis,
 When you say don't work do you mean don't adjust the volume or do you mean
don't interact with the software? B/c I have an x23, x30, x40, x60 and it works
on all of them. It does not, however, display on the screen unless I install tpb.

So, how do you mean yours  are broken?
Comment 6 Luis Villa 2007-10-07 14:55:53 EDT
None of the volume levels in gnome-volume-control are affected by using the
volume keys, which is what I was looking at (since I had no music on the liveCD
system, and forgot about the web radio.) But you're right, there is some other
system-wide volume that is affected without any on-screen-display.

So, I guess there are a collection of things broken here:
* no on-screen display for the system-wide volume
* system-wide volume not represented in gnome-volume-control
* system-wide volume not represented in the volume applet

(plus presumably bug 247468, unless that was fixed without the bug being closed.
Can't test on the livecd.)

But yeah, the original title is wrong- I've updated it. (I haven't tested any of
the latest bits on the x31.)
Comment 7 David Zeuthen 2007-10-07 17:30:33 EDT
If you go into the "Keyboard Shortcut" capplet and manually configure the keys
does it work? (it's also /usr/bin/gnome-keybinding-properties)

I *think* that the bug is that we don't ship any sane defaults here; e.g. all
the work lower in the stack actually properly remap the keys such that they emit
XF86_Key_LowerVolume or similar. 

(FWIW, this works for me on a Dell Precision M65 where mute=0xa0, voldown=0xae,
volup=0xb0.)

(and if this is correct we need to assign the bug to control-center and get this
fixed)
Comment 8 Luis Villa 2007-10-07 17:47:20 EDT
davidz: the keybinding-props capplet doesn't seem to recognize the keys at all
(and definitely no default setup for voldown/volup/mute.) Next step to test
where in the stack the problem is?
Comment 9 David Zeuthen 2007-10-07 17:48:59 EDT
Created attachment 218911 [details]
screenshot

Talked to krh and there are two things to this

 1. We ship with the wrong keyboard model (it's an xkb thing; krh will look at
it); doing setxkbmap us+inet will fix it runtime while in X but we need to fix
the default

 2. We need to ship the GNOME keyboard shortcuts set to AF86AudioMute etc.; see
attached screenshot
Comment 10 David Zeuthen 2007-10-07 17:50:10 EDT
(Reassigning to proper component)
Comment 11 Stephen 2007-10-08 07:49:27 EDT
Re comment 7: running the Keyboard Shortcut capplet...

Which volume does the 'volume up' action control, the global software mixer?
Many thinkpads have a hardware mixer which is controlled by the multimedia keys
directly. If the keys are mapped to the global software mixer, two volumes will
be adjusted. But, if the software sliders are manipulated, only the software
mixer will be adjusted. Won't things get out of synch?

If the machine has a hardware mixer, this should be used instead of a global
software mixer. Or have I got the wrong idea about how this works?
Comment 12 Bastien Nocera 2007-10-09 10:32:08 EDT
(In reply to comment #6)
> None of the volume levels in gnome-volume-control are affected by using the
> volume keys, which is what I was looking at (since I had no music on the liveCD
> system, and forgot about the web radio.) But you're right, there is some other
> system-wide volume that is affected without any on-screen-display.

The mixer is a separate mixer, and will show up as a different device in
gnome-volume-control when ibm-acpi is loaded.

> So, I guess there are a collection of things broken here:
> * no on-screen display for the system-wide volume
> * system-wide volume not represented in gnome-volume-control
> * system-wide volume not represented in the volume applet

They're all due to the module being missing.

(In reply to comment #9)
> Talked to krh and there are two things to this
> 
>  1. We ship with the wrong keyboard model (it's an xkb thing; krh will look at
> it); doing setxkbmap us+inet will fix it runtime while in X but we need to fix
> the default

Or we could switch to evdev as the keyboard driver, which should take care of
that. Please file another bug about this.

>  2. We need to ship the GNOME keyboard shortcuts set to AF86AudioMute etc.; see
> attached screenshot

That sounds like a good idea, but it's one for a different bug (filed as bug 324931)

Luis' bug is due to ibm-acpi not being there, reassigning to the kernel.
Comment 13 David Zeuthen 2007-10-09 10:58:11 EDT
(In reply to comment #12)
> Luis' bug is due to ibm-acpi not being there, reassigning to the kernel.

True, however what I mentioned in comment 9 _also_ needs to be fixed for this to
work out of the box.
Comment 14 Chuck Ebbert 2007-10-09 13:59:37 EDT
(In reply to comment #12)
> Luis' bug is due to ibm-acpi not being there, reassigning to the kernel.

It's called thinkpad_acpi now, and it is there. But the keyboard functions might
not be working the way you want them to after a commit was merged three weeks ago:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ff80f1370f2eff7dd7a828cf2416bf7be697247e
Comment 15 David Zeuthen 2007-10-09 17:55:06 EDT
(In reply to comment #14)
> (In reply to comment #12)
> > Luis' bug is due to ibm-acpi not being there, reassigning to the kernel.
> 
> It's called thinkpad_acpi now, and it is there. But the keyboard functions might
> not be working the way you want them to after a commit was merged three weeks ago:
> 
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ff80f1370f2eff7dd7a828cf2416bf7be697247e
> 

What we need is 

 a. thinkpad-acpi to be automatically loaded; e.g. it should use the DMI code
that Lennart wrote some time ago. Chuck, does it do that already? (sounds like
it doesn't)

 b. a version and/or configuration of thinkpad-acpi that provides input devices
to feed the keypresses (it sounds, from the link, this is the case)

 c. someone to fix xkeyboard-config cf. comment 9 above
    (and this is not thinkpad specific)

I'll check with my old Thinkpad T41 tonight or tomorrow.
Comment 16 Luis Villa 2007-10-09 18:07:28 EDT
<i> a. thinkpad-acpi to be automatically loaded; e.g. it should use the DMI code
that Lennart wrote some time ago. Chuck, does it do that already? (sounds like
it doesn't)</i>

Just to be clear, thinkpad-acpi is getting loaded, at least on this x41 tablet.
Comment 17 Chuck Ebbert 2007-10-10 14:09:42 EDT
From the comments for that kernel commit:

The module parameter was added to allow thinkpad-acpi to work with
userspace that has been partially updated to use thinkpad-acpi input
devices, but not the new ACPI core netlink event interface.  To use this
mode of hot key reporting, one has to specify the hotkey_report_mode=2
module parameter.

So maybe we just need to just add "options thinkpad_acpi hotkey_report_mode=2"
to modprobe.conf?
Comment 18 David Zeuthen 2007-10-10 15:43:08 EDT
Luis, can you attach output of lshal? Thanks.
Comment 19 David Zeuthen 2007-10-10 15:56:51 EDT
Also, why're we're at it; does the kernel (specifically atkbd.c) print out
spooky stuff like mentioned on this page?

http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-scancodes.html

My hunch is that we need keymap quirks for your model. Unfortunately I don't
have the hardware to test this myself (my T41 requires no key remapping).

Thanks again.
Comment 20 Luis Villa 2007-10-10 23:23:41 EDT
Created attachment 223811 [details]
lshal
Comment 21 Luis Villa 2007-10-10 23:25:14 EDT
[fedora@localhost ~]$ dmesg | grep atkbd
[fedora@localhost ~]$ 

So that's that.
Comment 22 Jeremy Katz 2007-10-22 21:29:21 EDT
This should be better as of rawhide of the end of last week.  We now
1) Get keyboard events when you press the buttons (this was pushed upstream and
committed, also included as a patch in our kernel package)
2) Default keymap on new installs (+livecd, etc) for the us keyboard is us+inet.
 We'll get the other locales on the next release, but I just don't have the
confidence in them while I have a lot of US keyboards to try with
3) Default setup in GNOME uses XF86AudioMute, etc

Note that the first is the only Thinkpad specific bit of the changes really; the
others all benefit all laptop users (as long as the key presses are recognized
or appropriately quirked in hal)
Comment 23 Luis Villa 2007-10-23 08:29:16 EDT
Does work better in rawhide as of 10/19. Thanks, Jeremy.
Comment 24 Luis Villa 2007-11-04 08:50:52 EST
Hrm, since I upgraded to F8 instead of doing a clean install, what is the One
True Way to switch from us to us+inet? I don't seem to see anything
corresponding to that anywhere. (I know this is OT; apologies.)
Comment 25 Jeremy Katz 2007-11-04 08:56:27 EST
Run system-config-keyboard, set to US layout and it should happen.  The next
time you log in, GNOME will ask if you want to use the X keyboard settings or
keep what you've previously had; select the X settings.
Comment 26 Luis Villa 2008-09-11 15:48:26 EDT
FWIW, this has regressed in latest F9 (unfortunately not exactly sure when this started because I didn't use the box much over the summer); specifically the IBM keyboard volume keys again seem to be modifying a different, 'hidden' volume that doesn't show up in gnome-volume-control or volume applet, and which doesn't impact the on-screen volume display.

Oddly, the volume keys on my MS Natural Wireless work as expected.
Comment 27 Luis Villa 2008-11-30 21:55:46 EST
Regression continues on F10, as described in my last comment.
Comment 28 Michael Hughes 2009-01-01 01:55:51 EST
Same in F10.

I'm not sure exactly how this is supposed to be implemented, but neither lshal --monitor nor xev catch an event when vol-up/vol-down/mute are pressed on my T43. Works fine in Ubuntu 8.10.
Comment 29 Michael Hughes 2009-01-01 01:56:02 EST
Same in F10.

I'm not sure exactly how this is supposed to be implemented, but neither lshal --monitor nor xev catch an event when vol-up/vol-down/mute are pressed on my T43. Works fine in Ubuntu 8.10.
Comment 30 Bastien Nocera 2009-01-05 06:59:43 EST
*** Bug 444055 has been marked as a duplicate of this bug. ***
Comment 31 Matthew Garrett 2009-03-03 10:25:11 EST
I suspect that previous behaviour can be obtained by doing

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

This will forcibly enable the hotkey reporting. The reason this isn't done by default is that hitting these keys will control the hardware mixer even if they also generate events that control the software mixer. The easiest way to do verify this is to hit the mute key. The mixer applet should now show that the system is muted. Right click on the mixer applet and unmute it. Now try to play sound. If the firmware is still controlling the hardware mixer, the sound will still be muted. Hitting a volume key on the keyboard will reenable it.

Generating events in this case allows the OS and the hardware to get out of sync in terms of the mixer status, so the default behaviour is not to generate these events right now.
Comment 32 Luis Villa 2009-03-03 10:51:20 EST
(1) that does 'fix' it.
(2) I removed the software applet from my panel so long ago that I guess I never noticed the possibility to get out of sync. That's a shame. Mind you, they *get out of sync anyway* (because you haven't made those buttons go away) just in a different way. So at least on this particular model either situation is a big user experience fail.
Comment 33 Jesse Kahtava 2009-03-03 10:53:11 EST
I can confirm that the above suggestions makes the volume control work as one would expect and like previous versions of Fedora.
I just threw that command in /etc/rc.local
Comment 34 Matthew Garrett 2009-03-03 10:57:44 EST
They can still get out of sync, but there's no indication given that they're controlling the same thing. In the case of sending events the impression is given that the software mixer is the sole component involved. I'd lean towards thinking that that's more confusing, but if people disagree in general then we can probably alter the default behaviour here.
Comment 35 Luis Villa 2009-03-03 11:01:34 EST
"there's no indication given that they're controlling the same thing."

Seriously? Besides that they are both volume up, volume down, and mute buttons? 

Even I didn't realize that hardware and software volume might be separate things until this bug, and I'm not exactly new at this.
Comment 36 seth vidal 2009-03-03 11:07:11 EST
I'd be in favor of reverting the buttons to operate on hw

I like that if I'm screenlocked then pressing mute works.

I also like that if my sw if screwed up somehow the button still does SOMETHING.
Comment 37 Jesse Kahtava 2009-03-03 11:21:37 EST
I don't think any of your concerns are actually problems with either implementation. For me all of those situations have worked either way. The only difference I've encountered is that one way will reflect the changes in software.
Comment 38 Stephen 2009-03-03 15:40:00 EST
How about this:

Re-enable events.  If a hardware mixer is available, then whenever an event is received the hardware mixer needs to be polled (by the volume control applet?) to see if it's volume has been changed. Reflect this in the interface.

This also needs to work with the new Flat Volume feature for F11:

    https://fedoraproject.org/wiki/Features/VolumeControl

...where a single volume is exposed to the user: a combination of hardware and software mixers.

Ping Lennart?
Comment 39 Matthew Garrett 2009-03-03 15:47:16 EST
The Thinkpad hardware mixer is currently not exposed as an ALSA mixer device, so that would need doing as well.
Comment 40 Richard Hughes 2009-03-03 16:00:24 EST
(In reply to comment #39)
> The Thinkpad hardware mixer is currently not exposed as an ALSA mixer device,
> so that would need doing as well.

I wrote a patch to do this about a year ago. It's on the ibm-acpi mailing list if you are interested.
Comment 41 Mason Sanders 2009-03-03 18:27:53 EST
so i was fooling with F10 and my Lenovo T60 widescreen this morning trying to get the volume keys to once again interact with the gnome volume controls.  One of the guys that works for me told me to do the following (cat just there for before and after reference) and now I am 90% working

[root@msanders ~]# cat /proc/acpi/ibm/hotkey 
status:		enabled
mask:		0x008c7fff
commands:	enable, disable, reset, <mask>

[root@msanders ~]# echo 0xffffffff >/proc/acpi/ibm/hotkey

[root@msanders ~]# cat /proc/acpi/ibm/hotkey 
status:		enabled
mask:		0x00ffffff
commands:	enable, disable, reset, <mask>


This gets the hardware keys to show up in lshal -m and showkey once again and it also changes the gnome volume slider when you change the hw volume.  The hitch is that if you mute the volume by pressing the hw mute button and then you unmute by right clicking the gnome panel icon, the icon changes, but the volume is still muted.  I hope this helps someone that is smarter than me figure out what is actually happening.
Comment 42 Mason Sanders 2009-03-03 18:33:00 EST
i guess when you read a bug at 10 am, you should read it again at 6pm before you post something that has already been said.  /me hides.
Comment 43 Bastien Nocera 2009-03-04 18:20:52 EST
*** Bug 488620 has been marked as a duplicate of this bug. ***
Comment 44 Timothy Grondin 2009-04-02 00:19:24 EDT
Is there any further testing that is needed to fix this fedora bug?
I'd be happy to help out. 

I have a thinkpad r52 that has this issue. It is massively annoyning since I use the physical sound buttons most of the time.
Comment 45 Jonathan Pritchard 2009-07-31 07:28:59 EDT
I hope this is the bug I've been looking for. On my Thinkpad T400, the brightness and volume keys show up the OSD, they also generate events that show up in 'lshal -m' but the mute key does not, although it does mute the volume (presumably in hardware) the gnome volume applet does not show a change of state nor does the OSD pop up with the appropriate mute icon.
Comment 46 Bug Zapper 2009-11-18 04:32:33 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 47 Bug Zapper 2009-12-18 00:59:13 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.