xcape features (double bind modifiers)

[timokau]

Hi,
For me currently the main thing that stops me from giving wayland a try, is missing xcape support.
Now alols/xcape#67 is open for a while, and it doesn't seem like its going to come anytime soon or even is possible.
Is it correct, that the windowmanager would have to implement these features?
If so, have you considered implementing them?

My specific use-cas is:

• Bind Caps to ctrl when I hold it, escape else
• Bind Tab to alt-gr when I hold it, Tab else

[ddevault]

I think you should pitch this to libinput.

[timokau]

Thank you, I did.

[timokau]

They won't fix, apparently its too high-level for libinput.

[ddevault]

Ugh. I'll reopen this but I'm not sure how I want it to take shape in sway.

[timokau]

Thanks
It wouldn't really be a good solution if every compositor had to implement this (although I think that especially people using tiling window managers may profit from this).
But if its the only one, I'm glad that you at least consider it.

[progandy]

Is this even possible in sway without changing wlc? I think the whole keymapping is hidden and not accesible.

[valpackett]

Looks like this might be easier with wlroots.

Plus, here's an idea! Since every problem in Wayland is solved by inventing a protocol…

We need one that's kinda similar to xwayland-keyboard-grab, but:

• obviously, not an exclusive grab — keypresses must be copied to the client;
• the client should provide the set of keys it's interested in — the compositor can implement security policies based on that. e.g. sway can have two different permit levels, watch-modifier-keys and watch-all-keys, or just allow everyone to grab modifier keys (they're not that interesting after all) and require permit watch-keys for a keylogger;
• and of course, the interface should also include a request that injects keypresses back.

Example flow:

• the hypothetical wcape or waycape or whatever requests watch_keypresses(wl_seat, ['Shift_L', 'Shift_R', 'Control'])
• the user presses and releases Control in a terminal window
• the compositor sends an event for Control to the terminal (which ignores it), but also sends that event to wcape because it's registered for that key
• wcape reads the event and requests inject_keypress('Escape')
• the compositor sends an event for Escape to the terminal

Bonus idea: clients can request a "secure mode" like in macOS, so when you're entering a password, events would not be copied to wcape. (Not super necessary when only giving access to modifier keys, but would be great for, like, running a keylogger for typing statistics I guess :D)

[Timidger]

Seems annoying to have to define a whole protocol for this...but it is the most compositor agnostic option :\

Unless there was some other layer above libinput that's implemented that can implement this and all the compositors start using that. Though that seems mostly unnecessary and even less likely than all the compositors using the same protocol.

[valpackett]

Yeah, just setting xcape style key presses is simple enough to do directly in compositors, but this protocol allows for more stuff, such as TextExpander-like apps, typing statistics, etc.

[valpackett]

What do y'all think about this protocol?

[ddevault]

-1. This is not something I'm interested in doing with a protocol.

[valpackett]

So it won't be possible to do UI automation/testing/macros (java.awt.Robot, Sikuli, xdotool etc.), text snippet expansion, keyboard typing statistics, etc. under Sway?

I guess I'll have to do this on evdev level then. It's possible to listen directly on evdevs and create a fake keyboard (uinput on Linux, cuse on FreeBSD) to inject events. I believe that a Wayland protocol would've been a much cleaner and better solution >_<

[ddevault]

I don't think that any of those use-cases justify putting in what is literally a keylogger protocol extension.