Bug 841419

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.

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.

Isn't this a kernel issue now?

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.

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.

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

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.

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.

(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!

Created attachment 970630 [details]
30-keymap-module-thinkpad-acpi.fdi

update of 30-keymap-module-thinkpad-acpi.fdi with proper touchpad toggle key mapping

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)

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