Protocol for requesting keyboard modifiers

[harishkrupo]

The idea is to use the change in modifiers information to be notified about the change in keyboard layout. This is useful for applications like status bar to show the current keyboard layout. Please see https://github.com/swaywm/wlroots/pull/1360 for more information.

[emersion]

I wonder if we could build a more general protocol. Can this be useful for other use-cases too?

Also, do we want to only provide modifiers, or do we want to provide more info?

[harishkrupo]

I wonder if we could build a more general protocol. Can this be useful for other use-cases too?

There could be other use cases but I am unable to think of any.

Also, do we want to only provide modifiers, or do we want to provide more info?

More info as in, other events or more info along with the modifiers? As for other events, sending key events could be dangerous. Maybe KeyEnter/KeyLeave along with the client to which it was sent? This could be useful for another applet which shows the application which has the current focus. But I guess we could get this information from swaymsg -t get_tree. As for more info, we don't need more info for this use case but may be needed for other usecases?

[harishkrupo]

Would something like this work? https://github.com/harishkrupo/wlr-protocols/commit/096664047a4d22ffaab4d6271d58a8f8ded47eb3 Sorry if it is not proper, I have never written a wayland protocol before.

[ddevault]

I don't actually understand what's supposed to happen after the client calls get_keyboard_modifiers with need_events = 1.

[emersion]

@harishkrupo Wayland protocols aren't RPC, they're asynchronous. You don't "call" methods, you send requests. Requests don't "return" values, instead the compositor can send events to clients.

[emersion]

I wonder if it's worth it to have such a specific protocol.

[ammen99]

@emersion This seems a nice addition to have (IMHO). But I'm not sure, can't the app somehow get this from the wl_keyboard?

[emersion]

This seems a nice addition to have (IMHO). But I'm not sure, can't the app somehow get this from the wl_keyboard?

If it's focused, yes. It doesn't work if it's a statusbar though.

[harishkrupo]

@emersion @SirCmpwn @ammen99 The request is asynchronous. When the client declares that it wants the events by setting need_events=1, the compositor can add that to the list of clients that want the modifiers and send the modifiers to them along with the focused client. In my wlroots RFC here https://github.com/swaywm/wlroots/pull/1360, I had added this request to wlr layer shell and when the client calls this it gets registerd for the modifier events, the events are sent in wlr_send_keyboard_modifiers Here: https://github.com/swaywm/wlroots/pull/1360/commits/cb53d4df899895f75b9fafd800f3f78cc5a12aba#diff-b012ce40ba3e8e49502f88dcfe15cc2cR219

[emersion]

I'd rather not change wl_keyboard semantics. Instead, it would be better to add a new interface with a modifiers event.

[harishkrupo]

I'd rather not change wl_keyboard semantics. Instead, it would be better to add a new interface with a modifiers event.

Sorry, I didn't understand. Could you please explain?

[ammen99]

Sorry, I didn't understand. Could you please explain?

@harishkrupo What you do is reusing the wl_keyboard modifier event. It would be better if you just add an event modifiers in the new protocol you're writing, so that you don't use wl_keyboard in a way it is not intended to.

[harishkrupo]

@ammen99 Thanks. got it :)

[harishkrupo]

okay, updated it. https://github.com/harishkrupo/wlr-protocols/commit/a868f4e4d3a122bd588c0bc86b25188190de6e00

[emersion]

This doesn't work when there are multiple seats (ie. multiple wl_keyboard).

Instead we'd need a request to create a wl_keyboard wrapper (a new object), which has a modifiers event.

Note: I'm still not sure this protocol is a good idea.

[harishkrupo]

This doesn't work when there are multiple seats (ie. multiple wl_keyboard).

Instead we'd need a request to create a wl_keyboard wrapper (a new object), which has a modifiers event.

Makes sense.

Note: I'm still not sure this protocol is a good idea.

Any other alternative way to get layout details?

[emersion]

Any other alternative way to get layout details?

Another alternative would be to have the sway IPC do this. It's probably not a better solution considering that it's sway-specific.

Has someone else thoughts about that?

[harishkrupo]

@emersion I have updated based on your comments https://github.com/harishkrupo/wlr-protocols/commit/e6d8577c6f744e8ad61d8cd2fc9aa1ac9e770d0d

[emersion]

The structure of the protocol looks good. Only missing thing is a destroy request in the first interface.

[harishkrupo]

Okay, will add that. BTW, why don't we have a destructor here: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml#L28 ? I actually copied this and edited it :)

[harishkrupo]

@emersion I have added the destructor request. https://github.com/harishkrupo/wlr-protocols/commit/d9c82c1f25bcb8e1386f3f84c2813b44c8081dec If it is good shall I open a PR?

[emersion]

If it is good shall I open a PR?

Sure.

@ddevault Thoughts?

[harishkrupo]

opened PR https://github.com/swaywm/wlr-protocols/pull/31

[emersion]

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/30