Skip to content
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.

Add wlr-keyboard-modifiers-unstable protocol #31

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

harishkrupo
Copy link

Signed-off-by: Harish Krupo harish.krupo.kps@intel.com

Signed-off-by: Harish Krupo <harish.krupo.kps@intel.com>
@ddevault
Copy link
Contributor

I think I'm still -1 on this protocol tbh.

@harishkrupo
Copy link
Author

I think I'm still -1 on this protocol tbh.

Do you have any suggestions to improve it?
Any other way to get modifiers then?

@lovesegfault
Copy link

I'd just like to add my support for this as a user. I constantly switch between three languages that require distinct layouts, and it's super helpful to have my status bar display the current one. I get that this protocol might seem too specific, but I feel like it addresses an important point. Thanks @harishkrupo for putting in the work for this, and @emersion and @ddevault for giving feedback and guidance!

@AdrianVovk
Copy link

As a DE dev, I would also like to vouch for the usefulness of this protocol.

@gdamjan
Copy link

gdamjan commented Jan 26, 2019

the protocol should probably be extended to get all the configured layouts (so that you can have a pop-up menu with all the layouts), and also to switch to another layout.

@ddevault
Copy link
Contributor

I'd just like to add my support for this as a user. I constantly switch between three languages that require distinct layouts, and it's super helpful to have my status bar display the current one. I get that this protocol might seem too specific, but I feel like it addresses an important point. Thanks @harishkrupo for putting in the work for this, and @emersion and @ddevault for giving feedback and guidance!

afaict this protocol does not fulfill this use-case. But you can fulfill this use-case anyway by just listening for keymaps on wl_seat, right?

@harishkrupo
Copy link
Author

afaict this protocol does not fulfill this use-case. But you can fulfill this use-case anyway by just listening for keymaps on wl_seat, right?

@ddevault, Does wl_seat advertise keymaps? I don't see any event for that here: https://gitlab.freedesktop.org/wayland/wayland/blob/master/protocol/wayland.xml#L1663

@ammen99
Copy link
Member

ammen99 commented Jan 27, 2019

I think that this protocol needs to be extended to be also able to switch the current layout (and possibly enumerate all layouts, if there is no other way to do that).

@emersion
Copy link
Member

emersion commented Jan 27, 2019

But you can fulfill this use-case anyway by just listening for keymaps on wl_seat, right?

No, because when you switch the layout, the keymap doesn't change (it contains multiple layouts). Instead, the modifiers change. We do send modifiers, but only to the currently keyboard-focused surface. So bars aren't notified.

Does wl_seat advertise keymaps?

See wl_keyboard.keymap.

I think that this protocol needs to be extended to be also able to switch the current layout (and possibly enumerate all layouts, if there is no other way to do that).

Is it possible at all to programatically switch layouts using the libxkbcommon API? EDIT: seems like it, since you know the number of layouts and you can set modifiers.

Enumerating all layouts is possible client-side using the libxkbcommon API. It gives names like English (US) though, not things like en.

Oh, and this protocol should include a keymap event too, since there's no guarantee it's sent to unfocused clients in the protocol.

@gdamjan
Copy link

gdamjan commented Jan 27, 2019

Enumerating all layouts is possible client-side using the libxkbcommon API. It gives names like English (US) though, not things like en.

xkbcommon/libxkbcommon#22
people suggested parsing evdev.xml (part of xkeyboard-config)

@emersion
Copy link
Member

people suggested parsing evdev.xml (part of xkeyboard-config)

All right. In any case, it doesn't belong to this protocol, and should be done client-side.

@ammen99
Copy link
Member

ammen99 commented Jan 27, 2019

Does the xkb state sent by the compositor also contain the list of enabled layouts?

@emersion
Copy link
Member

Does the xkb state sent by the compositor also contain the list of enabled layouts?

Yes.

@agx
Copy link
Contributor

agx commented Jan 30, 2019

Extending this a bit: what if a client (bar or shell) wants to listen to e.g. KEY_VOLUMEDOWN, KEY_VOLUMEUP or KEY_POWER. If we want to allow clients to handle this we might need a protocol to send certain input events to special clients (maybe using a whitelist in the compositor so clients can request certain input events but only get access to them if whitelisted).

@emersion
Copy link
Member

emersion commented Jan 30, 2019

Extending this a bit: what if a client (bar or shell) wants to listen to e.g. KEY_VOLUMEDOWN, KEY_VOLUMEUP or KEY_POWER. If we want to allow clients to handle this we might need a protocol to send certain input events to special clients (maybe using a whitelist in the compositor so clients can request certain input events but only get access to them if whitelisted).

Related: https://patchwork.freedesktop.org/patch/172113/

Note that in sway, we handle this by running commands instead of having some kind of "keybind protocol".

harishkrupo referenced this pull request in harishkrupo/Waybar Apr 2, 2019
This patch adds a new module to show the current keyboard layout.

Signed-off-by: Harish Krupo <harishkrupo@gmail.com>

<request name="get_wlr_keyboard">
<description summary="Create a wrapper over wl_keyboard">
Retruns a wrapper for the wl_keyboard passed as an argument. The

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Retruns a wrapper for the wl_keyboard passed as an argument. The
Returns a wrapper for the wl_keyboard passed as an argument. The

@emersion
Copy link
Member

emersion commented Nov 1, 2021

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

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/31

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

9 participants