Feature request: Pass XF86Audio*-Keys to i3 about i3lock

[Airblader]

This assumes that those keys are bound to those functions, which they might not be. Hence this introduces a security risk. Ill close for that reason.

[aiguofer]

Encountered this same issue. Found that the proposed commit presented here has been merged into https://github.com/PandorasFox/i3lock-color so you can just pass the --pass-media-keys option.

Hooray for forks and open source :) thanks everyone!

[jfrankenau]

If anyone is interested in a less hardcoded version than @bebehei's, have a look at 4d85b88. I have added an option to pass some XF86Audio* keys through to the root window by using xcb_send_event.

[stapelberg]

We’d like to keep the option surface as small as possible, and i3lock as secure as possible.

Any feature (such as this one) which allows you to intentionally or accidentally weaken your computer’s security has to be carefully considered, and this one just doesn’t tip the scales favorably enough for adding it, sorry.

[bebehei]

That's correct. Adding this without any configuration options will imply a security risk.

It would be great if you could give i3lock via options or configuration file some keystrokes, which are ok to pass to the wm while locked.

[bebehei]

@alecdwm No, this seems not to be fixed. But while viewing the changes, I got enough knowledge about i3lock.c to know where to patch it in a hardcoded manner.

At least it "works for me". See e4f2119

Thank you for your notification. I now had been able to fix it. I'm so happy.

[Airblader]

I don't think we want this kind of configurability in i3lock which we generally keep to be simple and safe. @stapelberg Agreed?

[stapelberg]

Agreed.

@bebehei If you want features like this, a more full featured desktop environment/screen locker might provide them.

[avindra]

Has anyone found a workaround for this? Or can suggest an alternative locker?

[alecdwm]

FYI: this issue appears to have been fixed in i3lock-color

[bebehei]

@tsuflux Well, have you opened a pull request?

[luislobo]

@stapelberg @Airblader what about the commit added by @jfrankenau 4d85b88 ? Seems like an easy and secure way of handling the multimedia keys.

[stapelberg]

It doesn’t address the fundamental concern originally stated in #52 (comment).

Feel free to use a fork with this feature, but for now, I don’t think we want this in i3lock.

[luislobo]

@stapelberg well, I partially agree, but:

• i3 is not run by normal regular users, normally people that know what they are doing
• the change in the commit needs a particular specific parameter to be set so that i3lock passes through those keys, it's not the "standard" mode.
• If an i3 kind of user doesn't know what their multimedia keys are doing (specially since you have to specifically configure the multimedia keys in i3 for them to work)... well, you are already in trouble.

[kpcyrd]

I think the original concern by @Airblader was about passing those keys by default. Since 4d85b88 is opt-in, the only risk is somebody explicitly enabling this feature without testing what those keys do on their setup. I think being able to quickly mute audio is a very reasonable request.

[luislobo]

That's fine. I'll just fork it.