Open rhysperry111 opened 1 year ago
This project exists to interact between the portal api and wayland protocols. Unless there is a wayland protocol created (eg. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/56) providing a comparable feature set this is blocked.
Because this is now a portal, I don't think that protocol is ever going to be finished. I am certainly not going to update it in favor of global shortcuts. So, what is the process of getting something in to wlr-protocols?
I don't think there is any. We can try making a PR to wlr-protocols ourselves for a global keybind protocol. I am always open to help with impls (both wlr and xdpw) if anyone's open to the idea.
wlr-protocols is closed and won't accept new protcols. Your best bet is the ext namespace in wayland-protocols.
How about intercepting the wayland-protocall like this proof-of-consept wayland-keylogger? https://github.com/Aishou/wayland-keylogger
Well assuming the shortcut portal service would have appropriate permissions you could just read input events directly in compositor agnostic fashion and ignore the compositor all together.
Maybe we could have a dedicated shortcuts demon that runs as root and send envry keypress to the client (XDPW).
Not in the scope of this project, but a potential workaround might be a wrapper script that has the ability to send keypresses to a client:
keypress-wrap --id discord --exec /usr/bin/discord
And a script to trigger a keypress send:
bindsym $mod+m exec keypress-send --id discord --key ctrl,shift,m
Maybe we could have a dedicated shortcuts demon that runs as root and send envry keypress to the client (XDPW).
All it's needed for this WM agnostic portal would be access to /dev/input nodes, so a root daemon, or the user adds themselves to the input
group, or maybe using the seatd api(? I'm not sure if seatd works like this).
A compositor agnostic portal is an interesting idea IMO.
This project exists to interact between the portal api and wayland protocols.
I'd suggest a clarification on this point: I think this project is a bridge between the portals APIs and the features in wlroots-based compositors that can implement those APIs, not necessarily the broader/upstream wayland protocols and ecosystem
Okay, so, I've read through:
From this, my understanding is that application developers (or developers of the frameworks/libraries used by application developers) need to do explicit work to adopt this:
My understanding of the sort of work that would likely need to be done here in xdg-desktop-portal-wlr:
dmenu
, etc)Maybe we could have a dedicated shortcuts demon that runs as root
This is a possible solution, but I don't believe it's necessary, the compositor is already trapping keyboard shortcuts without needing to run as root, the only thing that's different here is the DBus messages
All it's needed for this WM agnostic portal would be access to /dev/input nodes, so a root daemon, or the user adds themselves to the input group, or maybe using the seatd api
Likewise, this shouldn't be necessary
Well assuming the shortcut portal service would have appropriate permissions you could just read input events directly in compositor agnostic fashion and ignore the compositor all together.
My understanding of the GlobalShortcuts portal API, and the way KDE has implemented it, is that applications would not directly receive the keyboard events, they instead receive DBus signal messages
The above is all based on my understanding, however, so of course I could be wrong and I could have misunderstood how this is supposed to work
Your summary is mostly correct, the main issue is this point:
- wlroots-based compositors (e.g. sway/river/hyprland/etc) already allow keys to be bound to certain actions, so x-d-g-wlr should use the same wlroots APIs (during BindShortcuts) to bind the requested GlobalShortcuts
There is no wlroots api for this. compositors implement their own custom controls (usually keybinds) via a configuration file (eg. sway) or a program (eg. riverctl). xdpw is a separate wayland client and is not integrated in any compositor. xdpw only talks to the compositor via wayland protocols. As such we need a protocol to relay portal clients to the compositor. The mapping/decision logic will then again be in the compositor.
To clarify the situation is as follows: application <---- dbus -----> xdg-desktop-portal <----- dbus -----> xdpw <----- wayland ------> compositor
Okay, read through these and I can see that we're somewhat blocked:
There is another approach that allows for universal coverage of compositors without requiring root:
swaymsg
or riverctl
to bind the key:
busctl
or dbus-send
to send Activate/Deactivate to the application (or perhaps to x-d-p-??? acting as a proxy if it's too dynamic to be hardcoded)#! /usr/bin/env sh
swaymsg -t bindsym --no-repeat ${GLOBAL_KEY} exec 'busctl call ...'
swaymsg -t bindsym --no-repeat --release ${GLOBAL_KEY} exec 'busctl call ...'
swaymsg -t unbindsym ...
)The BindShortcut flow: application <---- dbus -----> xdg-desktop-portal <----- dbus -----> x-d-p-??? -----> user script ------> compositor
The key-press and key-release flow: compositor ------> sh ------> busctl / dbus-send <----- dbus -----> application or: compositor ------> sh ------> busctl / dbus-send <----- dbus -----> x-d-p-??? <----- dbus -----> application
A few downsides though:
sway
and river
support separate key-press and key-release bindings, but I'm not sure how common this is, so maybe this would only end up solving the issue for a small number of compositorsThere is no good way to achieve this without a wayland protocol.
What you could do is make a daemon like your xdp? and then make a binary that sends a keybind status, e.g. xdp-shortcut name pressed
xdp-shortcut name released
. (basically like swaymsg but for your daemon)
Not ideal, but it would work.
A proper solution is obviously a wayland protocol, like Hyprland does with hyprland_global_shortcuts_v1
and xdph.
You could either get a protocol of a similiar nature to wayland-protocols, or just adopt the hyprland one in your compositor of choice and use xdph.
In my uninformed opinion wlroots should just implement hyprland_global_shortcuts_v1
(if an implementation is even required), and either recommend a portal that bridges it, or add it to xdpw
, I'm all for not reinventing the wheel if there's already a viable solution available.
Currently there is a portal for registering global shortcuts in the works for xdg-desktop-portal v1.16.
I've just created this issue here to:
Since I don't think this is possible with current sway/wlroots, I presume it'd require a fair bit of development in both. Is this something that you think will be supported? The end goal is very similar to what the feature request of forwarding key events in sway would achieve.
Links: