I've set up a Samsung 90X3A from scratch (using BIOS boot to avoid a known related issue), and I'm having trouble enabling the screen brightness keys (Fn+F2 and Fn+F3).

The current state:

  • Manually setting the brightness works:

    sudo tee /sys/class/backlight/intel_backlight/brightness <<< 1000
    sudo tee /sys/class/backlight/acpi_video0/brightness <<< 50
  • xbacklight works:

    $ xbacklight -get
  • Fn+F2 and Fn+F3 are detected properly:

    $ sudo evtest /dev/input/event0
      Input driver version is 1.0.1
    Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab41
    Input device name: "AT Translated Set 2 keyboard"
    Supported events:
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event: time […], type 4 (EV_MSC), code 4 (MSC_SCAN), value 89
    Event: time […], type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1
    Event: time […], -------------- SYN_REPORT ------------
    Event: time […], type 4 (EV_MSC), code 4 (MSC_SCAN), value 89
    Event: time […], type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0
    Event: time […], -------------- SYN_REPORT ------------
    Event: time […], type 4 (EV_MSC), code 4 (MSC_SCAN), value 88
    Event: time […], type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1
    Event: time […], -------------- SYN_REPORT ------------
    Event: time […], type 4 (EV_MSC), code 4 (MSC_SCAN), value 88
    Event: time […], type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0
    Event: time […], -------------- SYN_REPORT ------------
  • ACPId is running:

    $ systemctl is-active acpid
  • xmodmap doesn't agree with evtest (but see below for attempted workaround):

    $ xmodmap -pke | egrep '224|225'
    keycode 224 = XF86Messenger NoSymbol XF86Messenger
    keycode 225 = XF86Search NoSymbol XF86Search

However, the screen brightness does not change.

There are heaps of advice around for dealing with this and similar issues. Here's what I've already tried:

Other possibly relevant system information:

  • X process tree:

    $ ps af -e --format user,cmd | sed "s/$USER/user  /g"
    USER     CMD
    root     /usr/bin/lightdm
    root      \_ /usr/lib/xorg-server/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    root      \_ lightdm --session-child 13 20
    user          \_ awesome
    user              \_ logger --priority user notice --tag xprofile-user
    user              \_ logger --priority user error --tag xprofile-user
    user              \_ xss-lock slock
    user              \_ cbatticon
  • Only one acpi_video0 xor intel_backlight should be able to set the brightness, not both. You should then be able to add something like Option "Backlight" "intel_backlight" (or acpi) to xorg.conf. I suspect that xorg is using the one that does not work. – grochmal Oct 8 '16 at 22:58
  • Both of them work, as does xbacklight, even after adding the backlight option to /etc/X11/xorg.conf. And no warnings or errors in /var/log/Xorg.0.log. So that doesn't seem right. – l0b0 Oct 8 '16 at 23:49
  • Hmm... it is the first time I see two /sys controls working. Random guessing now: xmodmap -pke | egrep '224|225'? and whether this works? (it is what I use, and the author is currently implementing the keyboard usage, look in the github issues for that) – grochmal Oct 9 '16 at 0:17
  • keycode 224 = XF86Messenger NoSymbol XF86Messenger, keycode 225 = XF86Search NoSymbol XF86Search – l0b0 Oct 9 '16 at 0:39
  • Wow! That doesn't seem right. It seems to contradict your evtest. My guess is that xmodmap -e 'keycode 224 = XF86MonBrightnessDown NoSymbol XF86MonBrightnessDown' and xmodmap -e 'keycode 225 = XF86MonBrightnessUp NoSymbol XF86MonBrightnessUp' have a good chance of making the keys work as they should. – grochmal Oct 9 '16 at 0:56

For now I'm working around this by hardcoding commands to handle the XF86 events in Awesome WM:

awful.key({}, "XF86MonBrightnessDown", function () awful.util.spawn_with_shell("xbacklight -dec 5") end),
awful.key({}, "XF86MonBrightnessUp", function () awful.util.spawn_with_shell("xbacklight -inc 5") end),

I'm still holding out for a solution to handle this independently of the window manager.

  • You will need some program to process the keys, so you might as well use the window manager that's already running ... or why do you prefer a different program that you'd have to run additionally? – dirkt Oct 10 '16 at 9:17
  • I would expect the OS to handle this without any manual configuration. – l0b0 Oct 10 '16 at 9:34
  • The OS doesn't handle it at all (and why should it? Linux runs fine without any sort of graphics display or keyboard). Some desktop environments handle it by running additional programs (without any manual configuration, in most cases), but you don't seem to have those installed. – dirkt Oct 10 '16 at 10:41
  • I don't have to implement my own boot loader. I don't have to set up my own compose key table. I don't have to create a colour scheme for top. And I should not have to bind extremely common keyboard shortcuts to commands. I would definitely expect this to be part of a very minimal working X desktop system. – l0b0 Oct 10 '16 at 17:29
  • Well, it is part of the bigger desktop systems. But if you don't run these, but use your own choice of window manager instead (which I do, too), and nobody wrote that part for that particular window manager (which is some effort, because there's lots of variations concerning backlight handling), then it's not there. And running an additional program that may conflict with the WM isn't the solution. :-) It's open source, contact the maintainers of Awesome WM and suggest to include it in the standard configuration. Which they probably won't do, because xbacklight doesn't work everywhere. – dirkt Oct 10 '16 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.