F1-F12 keys don't work

Question

I bought compact keyboard. F1 = Fn + 1 and F2 = Fn + 2 ... But F1-F12 keys don't work on my Ubuntu 16.04. For example F1 makes brightness up. I checked keycodes of F1-F12 keys and they are invalid. So F1 returns 232 keycode (instead 67).

I tried fix it using: xmodmap -e "keycode 232 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1" But it didn't help. F1 still change brightness. I tried remap other F1-F12 keys and no results. Xmodmap works only for non functional keys.

Is it possible to fix F1-F12 keys? (Swap keycodes?)

Xmodmap configured correct but F1 still change brightness:

$ xmodmap -e "keycode 232 = F1 F1 F1 XF86Switch_VT_1" # IT DON'T HELP!!

$ xmodmap -pke # everything is OK!
keycode  67 = F1 F1 F1 F1 F1 F1 XF86Switch_VT_1 F1 F1 XF86Switch_VT_1
keycode 232 = F1 F1 F1 XF86Switch_VT_1

$xev # take a look: XKeysymToKeycode = 67... F1... everything is OK again...
KeyRelease event, serial 40, synthetic NO, window 0x5000001,
    root 0xf5, subw 0x0, time 921326, (236,-87), root:(236,403),
    state 0x0, keycode 232 (keysym 0xffbe, F1), same_screen YES,
    XKeysymToKeycode returns keycode: 67
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
$sudo evtest 
Event: time 1497517949.369064, -------------- SYN_REPORT ------------
Event: time 1497517949.458895, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0

$ setxkbmap -print
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(qwerty)" };
    xkb_types     { include "complete"  };
    xkb_compat    { include "complete+ledscroll(group_lock)"    };
    xkb_symbols   { include "pc+us+inet(evdev)+capslock(swapescape)"    };
    xkb_geometry  { include "pc(pc105)" };
};

P.S. Also F1-F12 work properly on Windows.

Update:

Thank you @dirkt. Please take a look at the details:

1. I use Ubuntu 16.04.1 LTS Unity
2. /dev/input/event11: RK61 Bluetooth keyboard
3. sudo lsof /dev/input/event11 output: acpid, Xorg
4. evtest --grab /dev/input/eventX result: you are right, because the brightness of the Laptop screen stay the same (I've pressed Fn + 1 => F1)!

Trying to kill acpid process:

5. sudo kill 757 // killing acpid process
6. sudo lsof /dev/input/event11 output: Xorg // OK acpid killed
7. Pressing F1 -> Brightness is changing! // FAIL

Here is my rdesc file: https://pastebin.com/vxDvwMwr

Here is the hexdump: https:// pastebin.com/eT9mNnGV

Also I tried to change keycode via xkbcomp and it doesn't help.

Please write any thoughts. Thank you!

Answer 1

I found solution here: https://forums.gentoo.org/viewtopic-t-1063898-start-0.html

change behaviour on the fly 
# echo 2 > /sys/module/hid_apple/parameters/fnmode 

or modify it in config 
[/etc/conf.d/modules] 
module_hid_apple_args="fnmode=2 iso_layout=0"

Answer 2

Partial answer: The xmodmap mapping actually works correctly. As xev shows, you get keysym 0xffbe which is F1, as it should be.

So the question is (1) why it still changes brightness and (2) why it returns the keycode 232 (for KEY_BRIGHTNESSDOWN) instead of the one for the F1 key (67).

For (1), I suspect Ubuntu runs something by default the reads directly from /dev/input instead of processing X events, and this is processing the key no matter what xmodmap says. You didn't say which desktop environment you run (Gnome?). You can look with lsof for a process that directly reads the /dev/input/eventX source (you got the number X from evtest, numbers can change across boots). You can also test this theory by running evtest --grab /dev/input/eventX: This will make evtest the exclusive program to process the events, so when you press Fn+F1, it should still show KEY_BRIGHTNESSDOWN, but the brightness of your PC/Laptop screen should stay the same.

As for (2), googling the brand name shows it's a Bluetooth keyboard. This means it's likely a HID device. You can debug the by looking at dmesg to identify the corresponding hidraw device file and the bluetooth identifier. Then do

mount -t debugfs none /sys/kernel/debug

as root, and have a look at sys/kernel/debug/hid/*/rdesc for the correct device (look at available subdirectories). If you can't make sense of it, put it in a pastebin and edit the question with the link. Also, dump raw HID events using hexdump -C /dev/hidrawX, pressing Fn and F1, F2 etc several times. That should give you an idea why the kernel translates this the way it does.

Edit

Looking at the hidraw dump, the keyboard correctly produces scancodes 3a, 3b etc. for the function keys, as described in the HID descriptor.

So the problem must be in the HID-to-input translation layer.

You can interrogate this layer via ioctls. There's no public tool for this I know of, but I may put one up on github when it's done.

The only way to set this mapping I know is via the udev hwdb database as described e.g. here.

So I would guess who have some package installed that provides a database entry to map F1 to brightness control, and that also provides a program to react to this by directly monitoring /dev/input/event*. Try to see if you can find it on your system. lsof may help.