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.
maybe a bug in xkeyboard-config
Should be working with the ibm acpi module loaded. Richard?
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
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)
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?
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.)
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)
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?
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
(Reassigning to proper component)
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?
(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.
(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.
(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
(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.
<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.
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?
Luis, can you attach output of lshal? Thanks.
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.
Created attachment 223811 [details] lshal
[fedora@localhost ~]$ dmesg | grep atkbd [fedora@localhost ~]$ So that's that.
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)
Does work better in rawhide as of 10/19. Thanks, Jeremy.
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.)
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.
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.
Regression continues on F10, as described in my last comment.
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.
*** Bug 444055 has been marked as a duplicate of this bug. ***
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.
(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.
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
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.
"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.
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.
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.
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?
The Thinkpad hardware mixer is currently not exposed as an ALSA mixer device, so that would need doing as well.
(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.
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.
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.
*** Bug 488620 has been marked as a duplicate of this bug. ***
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.
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.
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
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.