3

I have recently moved to Linux full time, and am enjoying the learning curve. However, one particular thing has me stumped big time: Some of the Fn key combinations on my laptop are not working, spec. Volume up/down, Mute, etc. Combinations that are working include WLAN, Sleep, Video cycle, numeric pad, etc. I can rule out a H/W fault, since the keys worked perfectly fine on Windows 7 (although only when the hotkeys software by the laptop maker was installed).

I have scoured the net for possible explanations, and have come across the concepts of scancode (HW dependent), keycode and keysym. I think I understand the basics, and have found that console and X have their own mappings, and need to be remapped separately. The console uses the kernel mapping of scancodes to keycodes, but X for some reason has its own mapping. For my part, I have tried:

  1. Set the boot parameter atkbd.softraw=0
  2. Switched to console mode by Ctrl + Alt + F1
  3. Used showkey --scancodes. Unfortunately, the keys that I am trying to get working do not show any scancode output
  4. Used dmesg to see if any Unknown key pressed events have occured, but none found.
  5. In my desperation, tried acpi_listen to see if the keys were actually firing any acpi events instead, only sleep and video cycle keys do, others do not output anything

At this point, I thought maybe I should try getting scancodes from the X environment itself, using xev, but no luck.

I have come here as a last resort only. I hope somebody has a good explanation as to why some of the function key combinations are not generating any output in the tools I have tried above. If it helps, I am using Linux Mint 17.3 Cinnamon, and the laptop is made by HCL. evtest shows the keyboard device to be AT Translated Set 2 keyboard. If more info is needed, I would be happy to oblige. Thanks.

EDIT: No relevant BIOS setting is available.

Confession: All my knowledge on this is based on what I have been reading up on Arch wiki, Ubuntu wiki, a whole lot of forum posts and other websites. So, if I am technically wrong about something, please bear with me, and correct me. I love learning this stuff :)

oczkoisse
  • 1,561
  • 3
  • 17
  • 31

2 Answers2

0

Yes, some keys on USB keyboards might not generate a scan code sent via the USB HID keyboard protocol but instead use a different USB protocol to communicate some user input. From what you've described, that's most likely what's happening here. You may be able to use programs from the evmu-tools package (that's the Debian name) or the older evtest program to find out more about what your particular device is doing for things that appear not to be sending keyboard scan codes.

(It also seems, from reading The Unix & Linux SE question "How to get all my keys to send keycodes" that there's something going on with keycodes above 255, but I'm not clear on what's going on there.)

There's also an error in your understanding of the layering:

The console uses the kernel mapping of scancodes to keycodes, but X for some reason has its own mapping.

This is not quite correct. The kernel maps scan codes to keycodes between 1 and 255; you can see this mapping with getkeycodes(8) and change it with setkeycodes(8) or udev. (The Arch Wiki page Map scancodes to keycodes has many details on this.) Not all scan codes have a mapping to a keycode; receipt of a scan code with no translation entry are what you would have seen in dmesg, had there been any.

Only after the scan code is converted to a kernel keycode do the console and X11 have access to these; each has its own mechanism to translate keycodes to actions.

Note that the console program showkey -s does not show actual scan codes that have been received; it reads keycodes (as shown by showkey -k) and translates those back into scan codes using the kernel table shown by getkeycodes(8).

cjs
  • 25,752
  • 9
  • 89
  • 101
-1

It might depend upon the X11 window manager. You should try using xev(1) to understand what is going on.

Maybe using some other desktop suite like xfce or lxde or gnome, kde, icewm might help

Maybe configuring explicitly your keyboard (e.g. in /etc/Xorg.conf...) might help.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • I hope not, could you please elaborate how it might influence the situation. If I understand correcty, the scancode to keycode mapping depends on the X server implementation. Assuming a less than ideal mapping, how could it completely hide the scancode events? Surely, there must be some way to get these scancodes, right? – oczkoisse Jan 11 '16 at 13:18