Bug 841419 - Lenovo T420s Keymapping for Some Fn Keys and Mic Mute Button not working
Lenovo T420s Keymapping for Some Fn Keys and Mic Mute Button not working
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: hal-info (Show other bugs)
6.3
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Benjamin Tissoires
Desktop QE
: Desktop, Improvement
Depends On: 611987
Blocks: 1075802 1083163 1159933 667789 1170382 1191623
  Show dependency treegraph
 
Reported: 2012-07-18 18:59 EDT by Nino Sidoti
Modified: 2015-07-22 10:07 EDT (History)
8 users (show)

See Also:
Fixed In Version: hal-info-20090716-4.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1170382 (view as bug list)
Environment:
Last Closed: 2015-07-22 01:35:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Lenovo T420s maintenance manual (14.95 MB, application/pdf)
2012-07-18 18:59 EDT, Nino Sidoti
no flags Details
30-keymap-module-thinkpad-acpi.fdi (4.42 KB, text/plain)
2014-12-04 14:14 EST, Benjamin Tissoires
no flags Details
30-keymap-module-thinkpad-acpi.fdi (4.50 KB, text/plain)
2014-12-18 10:52 EST, Benjamin Tissoires
no flags Details

  None (edit)
Description Nino Sidoti 2012-07-18 18:59:16 EDT
Created attachment 599017 [details]
Lenovo T420s maintenance manual

Description of problem:Lenovo T420s laptop , keymapping for Mic Mute Button, Fn+F6 Webcam, Fn+F8 toggle for Touchpoint and Trackpad NOT Working.


Version-Release number of selected component (if applicable):


How reproducible:
Pressing Mic Mute Button does Nothing
Pressing Fn+F6 to change Webcam and Audio Settings, Camera Preview enables
Pressing Fn+F8 Change ultraNAV pointng device (touchpad or touchpoint)
Pressing Fn+ScrLK for NumLk has no Onscreen indicator. This key does work though.


Steps to Reproduce:
1.Press the key combination as described above
2.
3.
  
Actual results:
No Change or acton occurs when pressing the key combination using the Fn Key.


Expected results:
Look at the T420 maintenance Manual for expected results on page 57 Table 8


Additional info:
Comment 2 RHEL Product and Program Management 2012-09-07 01:29:01 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 6 RHEL Product and Program Management 2013-10-13 20:33:31 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 8 Richard Hughes 2014-03-10 13:28:20 EDT
Isn't this a kernel issue now?
Comment 9 Nino Sidoti 2014-10-13 18:47:53 EDT
Look it has been so long that I opened this call and I got completely frustrated with the time it takes to do something. So my part I tried. But it is obviously not a major bug and more cosmetic. 

Close this call as I no longer have the T420s and have moved on.
Comment 13 Benjamin Tissoires 2014-12-03 19:33:16 EST
There are two sides for this problem:
- the keys that are not mapped properly
- the LEDs which should be updated by snd-hda when the general or mic goes to mute/unmute.

I have split the bug in 2 so that we can keep traces of both sides.
This one is for the keyboard mapping only.
#1170382 is for the LED only.
Comment 14 Benjamin Tissoires 2014-12-04 14:14:01 EST
Created attachment 964803 [details]
30-keymap-module-thinkpad-acpi.fdi

Adding a hal rule which remaps from the user-space the keys into their actual keycode. Upstream remaps only mic-mute to F20, and the kernel handles the rest.

As a temporary workaround, we can remap all the keys from the user-space directly.

The attached rule replaces /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
Comment 15 Benjamin Tissoires 2014-12-04 16:51:53 EST
Actually, the hal solution is the best.

If we want to match upstream (having part of the fix in the kernel), we will still need to change hal because KEY_MICMUTE can not be handled by XKB. Upstream uses a hack which consists in remapping the KEY_MICMUTE to Fn20, but we can not do that in the kernel without diverging from upstream (and also reporting a fake random key without meaning).

Moving to the hal component.
Comment 17 Herton R. Krzesinski 2014-12-08 13:49:26 EST
Hi,

what's the status of this bug at the moment?

I'm looking at another support case opened by an IBM account (https://access.redhat.com/support/cases/#/case/01309352).

It's filled against RHEL 6.6. They report that the touchpad key toggle is not working.

Investigating, I noticed that the bits in 6.6 for the keymapping support regarding udev and X are there:

- udev sets the keymapping accordingly to scan codes sent by thinkpad_acpi driver:

From /lib/udev/keymaps/module-lenovo on RHEL 6.6:

0x1 screenlock # Fn+F2
0x2 battery # Fn+F3
0x3 sleep # Fn+F4
0x4 wlan # Fn+F5
0x6 switchvideomode # Fn+F7
0x7 f21 # Fn+F8 touchpadtoggle
0x8 f24 # Fn+F9 undock
0xB suspend # Fn+F12
0xF brightnessup # Fn+Home
0x10 brightnessdown # Fn+End
0x11 kbdillumtoggle # Fn+PgUp - ThinkLight
0x13 zoom # Fn+Space
0x14 volumeup
0x15 volumedown
0x16 mute
0x17 prog1 # ThinkPad/ThinkVantage button (high keycode: "vendor")

- X looks to handle F21 as touchpad toggle event as well.

But if you look at lshal input of the affected Lenovo machines on the support case (T420/W510), you have this:

sos_commands/hardware/lshal:  input.keymap.data = {'0x01:screenlock', '0x02:battery', '0x03:sleep', '0x04:wlan', '0x06:switchvideomode', '0x07:f22', '0x08:f24', '0x0b:suspend', '0x0f:brightnessup', '0x10:brightnessdown', '0x11:kbdillumtoggle', '0x13:zoom', '0x14:volumeup', '0x15:volumedown', '0x16:mute', '0x17:prog1'}

There is a conflict between the hal remapping and udev remapping for the touchpad key (udev remaps to F21 and X expects that, while the hal rule remaps to F22 as seen above). Also since udev now does the remapping, the hal rules are not needed anymore.

Also perhaps bug 611987 should be a duplicate or merged with this one? Or depend on this ticket.
Comment 18 Benjamin Tissoires 2014-12-08 16:58:39 EST
(In reply to Herton R. Krzesinski from comment #17)
> what's the status of this bug at the moment?

It's being worked on. I moved it to the wrong component, but now this should be fine.

> There is a conflict between the hal remapping and udev remapping for the
> touchpad key (udev remaps to F21 and X expects that, while the hal rule
> remaps to F22 as seen above). Also since udev now does the remapping, the
> hal rules are not needed anymore.

Yeah, the mismatch between the udev and hal mappings is a bug, both should map to f21 as that is what the X keymap defaults to. We will address this while resolving this keymapping bug.

> 
> Also perhaps bug 611987 should be a duplicate or merged with this one? Or
> depend on this ticket.

611987 is filled against gnome-settings-daemon, and we need it to correctly handle the touchpad toggle key. Adding this one as depending on the other one.

Thanks!
Comment 21 Benjamin Tissoires 2014-12-18 10:52:41 EST
Created attachment 970630 [details]
30-keymap-module-thinkpad-acpi.fdi

update of 30-keymap-module-thinkpad-acpi.fdi with proper touchpad toggle key mapping
Comment 29 Benjamin Tissoires 2015-03-11 09:57:35 EDT
With the config file mentioned in bug #1191623 and a kernel kernel-2.6.32-541.el6, the following command makes the LED and the correct pulseaudo setting working:
$> amixer set Capture toggle

Adding a custom shortcut in gnome to XF86AudioMicMute makes the key working properly (but still, there is no OSD for it, this has to be solved in bug #1167519)
Comment 32 errata-xmlrpc 2015-07-22 01:35:54 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1268.html

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