Xfce Forum

doodloo

Member

From: London

Registered: 2015-09-11

Posts: 59

XF86KbdBrightnessDown / XF86KbdBrightnessUp

Good morning everyone,

I'd first like to say that I have found the post [here](https://forum.xfce.org/viewtopic.php?id=8896) quite close to my original issue but didn't help. In fact I think my issue is a different one, but I'm not sure.

I recently purchased an Asus laptop:

sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
UX303LB.206
08/24/2015

After installing Xubuntu 16.10 on it, I realised that the screen brightness didn't work while pressing the keyboard keys with the relevant icons (fn + F5 / F6). I searched a bit online, and it was said that instead the keys fn + F3 and F4 had to be used. To be able to use them, I had to change the a couple of files:

Edit `/etc/default/grub` and put `acpi_osi= acpi_backlight=intel` in the default kernel arguments.
Create `/usr/share/X11/xorg.d/20-backlight.conf` reading:

Section "Device"
    Identifier "card0"
    Driver "intel"
    Option "Backlight" "intel_backlight"
    BusID "PCI:0:2:0"
EndSection

After updating grub and rebooting, programs like `screenkeys` show the indicator `XF86KbdBrightnessUp` / `XF86KbdBrightnessDown` when I press the fn + F3 / F4 keys.

So I tried mapping those keys as shortcuts using the XFCE keyboard settings. Here comes the super weird part: the tool asks me to press a key, and it records the correct one (Eg XF86KbdBrightnessUp), but then nothing happens when I press the key again. I know the keyboard shortcut system works on my system because I have many other set up. I tried binding something obvious to the keys (Eg start `evolution`), but it really doesn't catch the keys.

I mentioned the other thread at the begining of this topic because I noticed a major difference with my issue: when running `acpi_listen`, the codes are weird:

 PNP0C14:01 000000ff 00000000
 PNP0C14:01 000000ff 00000000

They don't match anything I can use, and most importantly they look the same to me.

Also... I don't know if it's relevant or not. Sometimes the letter `q` stop working inside of X. If I drop into a tty, the key works. Weird eh?

Is there anyone with similar issues who found a solution to this thing?

Thank you,
Doodloo.

Last edited by doodloo (2017-02-26 04:50:43)

booth

Member

Registered: 2016-05-11

Posts: 5

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

Hi doodloo,

First, are you trying to lower the screen brightness or the keyboard illumination brightness? I think the XF86KbdBrightnessDown/Up keys are for keyboard illumination. You might be looking for the XF86MonBrightnessUp/Down keys instead.

Second, it's hard for me to know exactly where your settings are breaking down, but I just posted my solution to simulating XK86 keys here: https://forum.xfce.org/viewtopic.php?id=11357

I tested the XF86MonBrightnessUp (don't have an illuminated laptop keyboard) using my solution posted in the other thread, and it worked consistently for me. Perhaps if your problem lies in getting the keypress to register, this will help you out.

Good luck!

doodloo

Member

From: London

Registered: 2015-09-11

Posts: 59

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

@booth you're right, X86KbdBrightness is usually for backlight on the keyboard, but the model I have doesn't have that feature. I think linux is confused with the keyboard and sees a feature while it should see another instead, this is why I wanted to use those events.

I'm going to see if I'm able to catch Fn + F5 / F6 manually with scripts similar to yours, and I'll come back here and report.

Thanks @booth

doodloo

Member

From: London

Registered: 2015-09-11

Posts: 59

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

Re @booth using xev to see what was happening showed that pressing fn + anything doens't register a valid keycode. No luck using xmacro, unless I change the modifier to meta or something like that, but not fn.

I think the issue is at a lower level, but I'm kind of stuck now. Maybe I need some kind of a driver to have those key combinations to register the proper codes.

So my initial question remains: if I want to use the X86KbdBrightness keys instead of the non-existent X86MonBrightness, how can I do so?
When registering my keyboard shortcut, the X86KbdBrightness key is registered, but then nothing happens when I press it.

Have a look at this picture:
http://i.imgur.com/cAIOixG.png

As you can see, I was able to register my shortcut, but when I press the key nothing happens. I know my script works, because when assigned to Ctrl + Alt + D, it triggers correctly. I guess the initial qestion could become "How can I map the XF86KbdBrightness events to something else as my hardware doesn't have backlit keyboard and those key codes are being incorrectly shown?"

Last edited by doodloo (2017-02-26 04:40:03)

doodloo

Member

From: London

Registered: 2015-09-11

Posts: 59

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

Anyone? Again to make it clearer:

Using the Keyboard -> Application Shortcuts application, I'm able to record the keys `XF86KbdBrightnessDown` and `XF86KbdBrightnessUp` but when pressing those keys again, the shortcut is not triggered.

Thanks

rfet35

Member

Registered: 2017-01-23

Posts: 21

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

Alternatively you could use triggerhappy hot key daemon to assign some action to those keys. There are packages for Ubuntu too: http://packages.ubuntu.com/search?keywords=triggerhappy

doodloo

Member

From: London

Registered: 2015-09-11

Posts: 59

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

Good afternoon,

Thank you @rfet35. Your insight was very helpful. Here is what I did.

1) I first installed triggerhappy by runnin as root: `apt-get install triggerhappy`.

2) Then, as triggerhappy expect a format of its own, I ran the daemon manually in "dump" mode over all my event sources.
As root: `thd --dump /dev/input/event*`.
When pushing my keyboard luminosity keys, it said that `KEY_KBDILLUMDOWN` was pushed.
I therefore knew that thd it was cappable of catching what XFCE isn't. I realised that thd's evens are raw kernel ones, as defined in her: http://lxr.free-electrons.com/source/in … des.h#L308

3) I started playing with thd's configuration files. I created (as root) a file `/etc/triggerhappy/triggers.d` containing the following lines:

KEY_KBDILLUMUP 1 /home/doodloo/.local/bin/simulatekey XF86MonBrightnessUp
KEY_KBDILLUMDOWN 2 /home/doodloo/.local/bin/simulatekey XF86MonBrightnessDown

Each time I was changing my file, I was killing and restarting my test command, namelly (and as root):

thd --triggers /etc/triggerhappy/triggers.d /dev/input/event*

I saw my script being called. Note that this `simulate-key` script just uses xmacro to push the key passed as argument 0 down and up again. I therefor

4) By reading further into `man thd`, I realized that thd actually had the ability to replace my key simulation script, if invoked using the `--uinput` switch. My test command evolved to:

thd --uinput --triggers /etc/triggerhappy/triggers.d /dev/input/event*

But it gave me an error message: "Error setting up uinput support.". I looked at triggerhappy's source code, and found out that the error was caused by its inabillity to use libinput.

I've looked into thd's source code, and my error is basically bubbling from this line: https://github.com/wertarbyte/triggerha … thd.c#L439
Unfortunatelly, since the log is vague, I can't know whether `uinput_dev` is null or if `open_uinput(uinput_dev)` fails. See bug report here: https://github.com/wertarbyte/triggerhappy/issues/18

Any idea? So far the solution works if used in conjunction with my scripts... But I'd like to remove the man in the middle and use thd with uinput to directly simulate the keys.

EDIT: Also, the trigger files in `/etc/triggerhappy/triggers.d` are useless when letting the system daemon run. See bug report here: https://github.com/wertarbyte/triggerhappy/issues/19

Thanks
Doodloo.

Last edited by doodloo (2017-03-12 14:23:08)

rfet35

Member

Registered: 2017-01-23

Posts: 21

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

Why don't you just use the triggers themselves to adjust the brightness instead of mapping to XF86 key events? eg:

KEY_KBDILLUMDOWN      1         DISPLAY=:0 xbacklight -dec 10
KEY_KBDILLUMDOWN      2         DISPLAY=:0 xbacklight -dec 10
KEY_KBDILLUMUP        1         DISPLAY=:0 xbacklight -inc 10
KEY_KBDILLUMUP        2         DISPLAY=:0 xbacklight -inc 10

As you said th works on kernel level, which gives you the advantage to work across all DEs or even on the console w/o any X server running. Writing directly to /sys/class/backlight/acpi_video0/brightness makes it completely independent of X.

edit:
I've just seen you mentioning using intel_backlight. xbacklight doesn't let you change intel_backlight. So in case you don't have acpi_video0 on your system you should write to /sys/class/backlight/intel_backlight/brightness instead.

Last edited by rfet35 (2017-03-12 18:51:19)

doodloo

Member

From: London

Registered: 2015-09-11

Posts: 59

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

@rfet35 thanks. But I don't think you understand the problem.

To recap:
- The fact that thd doesn't pick the key bindings when ran from a daemon completelly makes it useless (Bugreport #1  with their github repo).
- I don't want to use XMacro, xbacklight or any command line parameter with triggerhappy, because it has the ability to send events by itself (See its --uinput switch). But when enabling --uinput, triggerhappy crashes (Bugreport #2 with their github repo).

If you know how to solve either one of those bugs (The #1 making it a complete no-go), that'd be great!

EDIT: xbacklight works fine. It's not related to the current problem tho.
EDIT2: Yeah.... I don't think triggerhappy works correctly. When running it in dump mode, I can see KEY_LEFTALT+KEY_SPACE. But if I try to bind this to something, it doesn't trigger it even when I run thd manually.
EDIT3: Scratch edit 2 if you create your binding with KEY_LEFTALT+KEY_SPACE instead of KEY_SPACE+KEY_LEFTALT... This triggerhappy program seems to have many undocumented issues.
EDIT4: After binding synapse using triggerhappy (DISPLAY=:0 synapse), I had different graphical results than what should be displayed. I indeed asked triggerhappy to fallback to my used (not root). Clearly triggerhappy is not something that could be used in a graphical environment as a *replacement* for the standard keyboard binder.

I will uninstall triggerhappy:
- Lack of consistency,
- Bad X results with rendering,
- Unmaintained anymore,
- Baddly documented (Spending more than 30mn trying to figure why left alt is not binding, to discover that it's the order of the declaration that counts is not acceptable).

Bugreports:
- #1 https://github.com/wertarbyte/triggerhappy/issues/19
- #2 https://github.com/wertarbyte/triggerhappy/issues/18
I don't think these will be of any help, as there was activity on this project for the last 6 months.

So: back to the original issue... Why isn't the XFCE keyboard shortcut manager capable of catching events once it records them correctly? Again: I have no problem with brightness, when the XServer receives XF86KbdMonBrightness{Up|Down} it adjusts correctly. My issue is with the XFCE keyboard shortcut manager: It records my shortcut, but then never fires it.

Thanks a bunch
Doodloo.

Last edited by doodloo (2017-03-12 20:46:54)

rfet35

Member

Registered: 2017-01-23

Posts: 21

Re: XF86KbdBrightnessDown / XF86KbdBrightnessUp

Regarding #1

What's your DAEMON_ARGS?

Have you tried to specify the absolute device name of your keyboard instead of * (in my case: /dev/input/event0). I only had trouble when specifying the device by its /dev/input/by-path/... name. For some reason this did not work.
I'm currently running sysvinit scripts but I remember changing DAEMON_ARGS to the absolute path has also worked w/ systemd. If I recall correctly a reboot was necessary though.

Regarding #2

thd --uinput --triggers /etc/triggerhappy/triggers.d /dev/input/event*

I'm probably wrong about what --uinput does, but my understanding is that the device passed to it emulates input events (man: synthetic events). So I'm not quite sure why you would want to specify a real input device here. Especially not even an absolute device.