Add Wayland Support

[hasrack]

First of thanks a lot for making this app available for Linux. It only supports X11/xorg. Do you have any plan to support it under wayland in future? Are their in any difficulties to support it under wayland?

Again, thanks for the app.

[Merrit]

Most of what we rely on to interact with the system for things like hotkeys, checking for open windows, etc only currently exists for X11.

Wayland support might be workable, but it would require looking up / figuring out solutions for these things from scratch.

This is something I'd like to do as Wayland seems to be the way of the future, however I have limited time to work on Nyrna so I can't say currently when that would happen.

[Hikandy]

Any progress on this? This seems like a great app but on window managers such as sway, this seems not to work at all

[Merrit]

Any progress on this? This seems like a great app but on window managers such as sway, this seems not to work at all

Not as yet, I've been quite busy.

I would be happy to consider a pull request if someone wanted to look into this, otherwise it will be when I have some free time.

[Merrit]

I've done some more research and it looks like the things we need (list open windows, names, processes, etc) don't exist for Wayland still - though some proposals for such things are in draft stages.

[Northcode]

FWIW, for sway specifically, I've reimplemented the same functionality with some bash scripts: https://github.com/Northcode/dotfiles/blob/master/sway/bin/get-focused-pid https://github.com/Northcode/dotfiles/blob/master/sway/bin/toggle-psuspend

They require ps, pstree, grep and jq to work

you can bind it to a key like $mod+pause in your config with: bindsym $mod+pause exec toggle-psuspend $(get-focused-pid)

[Merrit]

For reference, this is the issue where this functionality is being discussed:

https://github.com/flatpak/xdg-desktop-portal/issues/304

Progress seems to have stalled for the time being, unfortunately.

[lnee94]

Well you could get the input directly from /dev/input. evtest a nice command to start with, but this would require root. Or you could take advantage of most DE having custom shortcuts which can run commands and at least for KDE you can import them. If a dbus endpoint was exposed to emulate the short cuts I could do the rest

[Rabcor]

Most of what we rely on to interact with the system for things like hotkeys, checking for open windows, etc only currently exists for X11.

Wayland support might be workable, but it would require looking up / figuring out solutions for these things from scratch.

This is something I'd like to do as Wayland seems to be the way of the future, however I have limited time to work on Nyrna so I can't say currently when that would happen.

Well, being able to pause windows by PID or something would come a long way, since it would mean we could pause windows from commandline.

Right now the Nyrna GUI does seem to be working in wayland (at least on Hyprland), however the problem is that the pause button doesn't work, it's because wayland is designed so that no application is supposed to be able to read the inputs to another application.

But it is possible to bypass this issue by just setting a global shortcut in your compositor, however nyrna --toggle does not work because it cannot detect the current window, so I need to go into nyrna's gui to pause anything with it.

Being able to pause a specific application or window from the CLI would give wayland users more options until any sort of official wayland support can be added (which, I'm not holding my breath for because wayland is kinda shit when it comes to things like this, at best support for wlroots can be added for something, but universal wayland support is an impossibility)

[Merrit]

the problem is that the pause button doesn't work

Can you clarify what you mean? To my knowledge the hotkey (Pause by default) works fine in Wayland - I tested it just now:

• env XDG_SESSION_TYPE=x11 kate
• With Kate focused, press Pause
• Kate suspends/resumes as expected

Does your experience differ?

[Rabcor]

the problem is that the pause button doesn't work

Can you clarify what you mean? To my knowledge the hotkey (Pause by default) works fine in Wayland - I tested it just now:

• env XDG_SESSION_TYPE=x11 kate
• With Kate focused, press Pause
• Kate suspends/resumes as expected

Does your experience differ?

I think maybe it depends on the compositor (the inherent problem for wayland support, everything depends on the compositor and nothing is standardized...) Sounds like you're on plasma wayland, maybe they somehow set things up for it to just work.

But did you try other compositors like sway? I'm on Hyprland.

Wayland is designed so that one window is not supposed ot be able to read keyboard inputs to another window (e.g. whenever there is another window focused), if they can it means the compositor is doing something to enable it, but it seems kind of a moot point to be using wayland if you're just patching out all it's "security" features over Xorg which was the main reason stated for wayland being made, doesn't it? (This particular feature is to prevent keylogging)

The only way to resolve this issue on Hyprland is global shortcuts, where the compositor intercepts certain key presses no matter what is focused and performs an action. Which means there'd have to be a way to make nyrna suspend applications from commandline in order to actually make the keybind work for many wayland compositors.

[guss77]

I think maybe it depends on the compositor (the inherent problem for wayland support, everything depends on the compositor and nothing is standardized...) Sounds like you're on plasma wayland, maybe they somehow set things up for it to just work.

As far as I can tell, Nyrna does not make use of the Global Shortcuts Wayland portal - at least kglobalaccess in my Plasma installation knows nothing about Nyrna.

I believe Nyrna uses the X11 protocol to read global shortcuts from XWayland apps, which is part of what Plasma calls "Legacy X11 App Support", and on my system it looks like this:

Which - as you can see - is off, but likely the way kwin works is that even when it is off X11 apps can still read keystrokes that are entered in other X11 apps. This actually makes a lot of sense if you know xlib.

If I use Nyrna's "application specific hotkey" to specify a key to pause Kate (when running under XWayland), that hotkey will not pause Kate when another Wayland application is active, but will pause Kate if another XWayland application is active.

I would guess that doesn't work for you in Hyprland (and possibly other wlroots friends) because they isolate X11 clients from each other. The first thing that I would check if to use ps to see how many XWayland processes you have when running Nyrna and another XWayland application - there should be only 1 that is shared between all X11 apps. If Hyprland has each X11 app run with its own XWayland instance - that could be the issue.

[Rabcor]

I think every xwayland application is run with the same xwayland instance, at least i don't see any duplicates.

[perroboc]

Was checking updates on plasma 6, and this popped up: https://www.youtube.com/watch?v=bWWQT3HamBw

Might be worth a look to save the state of games to disk

[flashgnash]

Also interested in Wayland support, haven't used x11 in almost a year now

Is it feasible to get any kind of CLI command to give a process ID, window class etc and pause/resume that?

That way hyprland/sway/etc users can setup their own keybindings in the window manager itself

Unsure how this tool works under the hood, if it depends on x11 for the actual pause/resume functionality but you mentioned not being able to get key inputs and window titles which this would sidestep at least

[Merrit]

Is it feasible to get any kind of CLI command to give a process ID, window class etc and pause/resume that?

The issue is that Wayland doesn't provide any way to get information about open application windows. This won't change until this issue is resolved: https://github.com/flatpak/xdg-desktop-portal/issues/304

As a workaround I have been hacking together a solution that will work specifically for KDE, though I haven't had time to finish it yet.

[materemias]

@Merrit please let us know here when the KDE specific workaround is available

[Merrit]

@Merrit please let us know here when the KDE specific workaround is available

I shall :)

Been ridiculously busy both with work-stuff and personal-stuff :face_with_spiral_eyes: but I will finish it up soon as I get a chance! :blue_heart: