--pass-media-keys, --pass-screen-keys and --pass-power-keys options do not work in DEs

[AladW]

This issue is a....

[X] Bug
[ ] Other kind of issue (Please describe in detail)

Current Behavior

In XFCE, using i3lock --pass-media-keys does not pass the media keys to the desktop environment. This happens regardless if the XF86 keys are bound in xfce4-settings, or through an external application such as volumeicon. I'm unsure why this happens, as --pass-media-keys works as expected in i3.

Expected Behavior

--pass-media-keys should pass the media keys to the underlying environment, regardless of the used window manager.

Reproduction Instructions

Install XFCE (pacman -S xfce4), bind XF86AudioMute either in keyboard settings or a program like volumeicon, try to mute when the screen is locked with i3lock --pass-media-keys.

Environment

Output of i3lock --version:

i3lock: version aur-2fd6547 (2019-09-20, branch "tags/aur-2fd6547") © 2010 Michael Stapelberg, © 2015 Cassandra Fox

Where'd you get i3lock-color from?

[X] AUR package (which one?)
`i3lock-color-git`
[ ] Built from source yourself
[ ] Other (Please describe in detail)

[PandorasFox]

Weird. Probably related to #131.

e: wait, it works when run over i3 but not when over xfce?

[AladW]

e: wait, it works when run over i3 but not when over xfce?

Yes, I never had any issues in i3. Can't say why, though. :/

[PandorasFox]

Huh, weird. Hopefully I can repro.

[AlonTzarafi]

I use OpenBox(with volumeicon) and also tried it on KDE-Plasma(with its own volume control) and on both of them the --pass-media-keys doesn't pass the media keys. Tried AUR i3lock-color-git and it still doesn't work

[darkelectron]

Also in bspwm. It was working on i3.

[Raymo111]

@AladW Is this still an issue for you? I think I'm getting the same issue as well.

[Raymo111]

So I've just tested GNOME, Plasma and XFCE. Seems like these options don't work at all. @PandorasFox Did you make the original pass-media-keys option? How exactly does

xcb_send_event(conn, true, screen->root, XCB_EVENT_MASK_BUTTON_PRESS, (char *)event);

work?

[PandorasFox]

iirc what that bit of code does is, if the flag is specified, it just passes back the specified keypress to the root window (essentially the window manager?). I'm not really sure what would need to be different for different DEs to work.

[Raymo111]

@PandorasFox Interesting, thanks.

[subnut]

I am in bspwm, and the keys are bound to sxhkd. Can confirm the same issue. 😭
But guys, this is like 9 months old. Any updates? This is like a deal-breaker to me. Really.
Please please please do something about it.

[Raymo111]

@subnut yeah, unfortunately, I've investigated far and wide, but I have no idea even which window in Plasma/KDE handles these events (for i3 it's simply root window), much less for all DEs. I need serious help on this one.

[moritzhoewer]

I just switched to i3lock-color for the --pass-media-keys as well, and it's not working for me either. Weird thing is, I am in fact using i3 as a WM.

I am not at all familiar with X11 / linux kernel Keyboard handling, but I noticed that if i run i3lock --pass-media-keys && xev, then I don't get KeyPress events, but instead I get KeymapNotify events for the media keys. If I run i3lock --pass-media-keys && sudo showkey I see all key presses (the ones for the password as well).

The reason I am posting this here is that it could maybe be related to the problems mentioned above.

I hope I can find time in the next days to investigate this further - if I find out anything usefull, I will post it here

[moritzhoewer]

I finally found some time to look into this some more. The problem seems to be that allthough I am using i3 as a window manager, I was using xbindkeys to handle volume control. I tried switching that over to i3 directly and now it works. So it seems that only i3 itself can receive key presses through the lock screen, and not any other program.

This only partially solves the issue for me though, since I would still like to pass the actual key presses for Play/Pause/Next/Previous to chromium.

Or to be more general...it would be great if --pass-media-keys and the related option could pass the keys to ANY program and not just the window manager, or is that deliberately not intended?

EDIT: If I understand this (https://www.x.org/releases/current/doc/man/man3/xcb_send_event.3.xhtml) documentation correctly, the propagate flag in xcb_send_event only allows the events to propagate up the hierarchy (at least that's how I understand anchestor). Since we are already sending to the root window here, propagate might as well be off. Only the root window actually sees the key anyway. I tried to find a way to do something like an "inverted" propagation (where the event would be propagated to the children and not the parents), but without success so far...

[Raymo111]

@moritzhoewer those keys already work in wms like i3 and dwm, that use the root window to control these functions. That's why the keys are passed to the root window. However, when using DEs, it's not the root window that parses these keys, and so it doesn't work; you have to send the keys to some window.

[moritzhoewer]

I see - and since i3lock has grabbed the entire keyboard, there is no way to just pass the key press through and let whoever would normally have handled that particular key handle it.

That is unfortunate...but I haven't found anything yet that would allow for what I am aiming at here, because that is probably not a use-case the X keyboard system was designed for.

[Rio6]

if --pass-media-keys and the related option could pass the keys to ANY program and not just the window manager

What if we add a param to pass in a window id to pass event to? Then one can use command like xdotool to grab the window id of whoever manages keybind and pass that in.

I don't use a DE though, so not sure how easy it is to get the target window there.

[Raymo111]

@Rio6 great suggestion. However, I couldn't find ANY documentation on which KDE (what I use, as an example) window even handles these things. I have a nasty feeling that even if I could find which window I wouldn't be able to use it statically (i.e. window id might change each startx and window might have no name)

[Rio6]

window id is definitely changing, but I'm hoping any of the window class, name, process name might stay the same. This will need some testing on different environments to know if it's actually viable tho.

Hopefully something like this can work.

i3lock --event-window-id $(xdotool search --class some-class-name)

[jclds139]

If I could make an alternative suggestion,
since the media keys passing doesn't work on other DEs, why not provide an option for setting up custom shortcuts instead? That way you can configure i3lock-color to, for example, send an MPRIS command with dbus-send when it gets an XF86AudioPlay event, or something like that. That seems more flexible, reliable, and secure than sending keystrokes back to the root window that could trigger anything (including, for example, killing i3lock or the X server).

All it needs to function is a syntax for mapping keysyms to commands, like

i3lock --shortcut XF86AudioRaiseVolume "pactl set-sink-volume @DEFAULT_SINK@ +5%"

Thoughts?

[Raymo111]

@jclds139 I feel like that would introduce unnecessary security risks (arbitrary command execution isn't really the best idea...)

[Rio6]

I personally don't like to maintain multiple copies of what each key does what :P, although I agree passing things to root window might not be the best solution (that's what this whole issue is about).

Running arbitary commands might not be that bad, considering whoevers running the i3lock command can also run whatever commands separately too (unless someone decides to suid i3lock binary...). But I don't think it's safer than sending events to root window anyways.

[jclds139]

My thought was it's slightly safer since the root window could do exactly the same thing, but in this case the i3lock binary controls what commands are run, as opposed to the root window that's out of the locker's control. I can see both sides to the argument, though.

[Raymo111]

Hmm you guys have fair points. This is starting to look like the best way to handle it.

Reference for KDE volume control: https://askubuntu.com/questions/422078/how-do-i-control-the-volume-in-kde-from-the-command-line

[JezerM]

I have the same problem with qtile.
Looking for some solutions, I guess xdotool would be great. If i3lock detects either "special" key, just run xdotool key {key}
xdotool key XF86MonBrightnessDown for example.

[Raymo111]

Will xdotool work though? Won't it get intercepted by the lockscreen and infinite loop?

[jclds139]

Anything xdotool sends would just get intercepted, I'm pretty sure. The commands need to get passed by something not X-related.

[JezerM]

That's what I don't know. In manpage, if no window parameter is set, it will use the "window stack" (if it exists) and send it to first window %1. Though, it's probably that it would be catched by i3lock.

[jclds139]

Yeah, that would have the same problem we're getting now: we can forward the key events, but need to know where to send them, and every DE handles hotkeys differently. That's why I suggested just calling commands so the user can set it up for their DE.

[Raymo111]

Yeah I think the commands are the way to go.

[JezerM]

I guess I've solved this.

When trying on Python, send_event methods didn't work, but fake_input did, so I replaced xcb_send_event with xcb_test_fake_input. The problem is that i3lock is "locking" the root keyboard, so this would create and endless loop, as @Raymo111 commented about xdotool.

Then, ungrab the keyboard, send the event to root, and grab the keyboard again was the solution.

I'm using Awesome WM, and this works to me.

[JezerM]

I tested it on Ubuntu... doesn't work... Seems like the volume and brightness UI breaks it.

Edit: Setting focus to i3lock after sending the key solves it.

[Raymo111]

Reopening because of #252 and #253.