Is it safe to use Key_BacklightDown and Key_BacklightUp?

Just like volume increase/decrease I was looking for a key name to map to increase LCD screen brightness and found this under key_defs.h: Key_BacklightUp and Key_BacklightDown. I wonder why this is not under the other “regular” headers but in this more low level file. So my question:

  1. Is it safe to use Key_BacklightDown and Key_BacklightUp in a keymap?
  2. Would it work on desktop LCD screens or only laptop? (Would test this myself if I were sure of answer to above question.)

Because backlight control is not part of the HID spec, and therefore these are non-standard codes. They may or may not work. It’s not unsafe, as in, it won’t destroy neither your screen or your keyboard. But it may not do anything. Or it might do something completely unrelated to screen backlight adjustment.

2 Likes

I’m also looking for a way to map screen brightness to something. I’m on macOS. Key_Backlight* seems to not do anything for me.

The keys didn’t work for me so I removed them from my keymap. Possibly they might work with laptops, I haven’t checked.

This could probably be achieved with a focos plugin…

Hopping in late to the party, but I have a laptop that already has dedicated brightness controls - I tried to map them to my keyboardio in multiple ways without success.

I am on Linux - KDE Neon with X.

As mentioned in x11 - How to get keycodes for xmodmap? - Unix & Linux Stack Exchange I ran xev to get the keycodes and got the following for the Brightness up/down keys:

KeyPress event, serial 40, synthetic NO, window 0x8e00001,
    root 0x191, subw 0x0, time 9995402, (706,-224), root:(706,421),
    state 0x2000, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x8e00001,
    root 0x191, subw 0x0, time 9995402, (706,-224), root:(706,421),
    state 0x2000, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 41, synthetic NO, window 0x8e00001,
    root 0x191, subw 0x0, time 9996594, (706,-224), root:(706,421),
    state 0x2000, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x8e00001,
    root 0x191, subw 0x0, time 9996594, (706,-224), root:(706,421),
    state 0x2000, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

But then started the weird stuff: I wanted to remap the keys to that code, but the codes defined in Chrysalis are totally different from the ones reported in the OS!

For Chrysalis codes over 220 nothing is reported to xev
Everything between 149 and 220 is reported as 248 in xev:

KeyPress event, serial 40, synthetic NO, window 0x6600001,
    root 0x191, subw 0x0, time 2658315, (1440,201), root:(1440,929),
    state 0x0, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

sudo showkey never shows anything for Chrysalis codes above 148.

I created a little table what maps to what:


The outputs of showkey and xev are internally consistent, that offset by 8 is normal as mentioned here: The Linux keyboard and console HOWTO: Examples of use of loadkeys and xmodmap
The outputs are also consistent with my internal keyboard.

But how are the keycodes from Chrysalis mapped to that, and how could I map them?

1 Like