Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KDE Wayland - Shortcut keys only work when xwayland window has focus #121

Open
TRPB opened this issue Feb 21, 2021 · 19 comments
Open

KDE Wayland - Shortcut keys only work when xwayland window has focus #121

TRPB opened this issue Feb 21, 2021 · 19 comments

Comments

@TRPB
Copy link

TRPB commented Feb 21, 2021

On KDE Wayland (Plasma 5.21 and earlier), Gromit-MPX's shortcuts (F9, I stuck to defaults) only work when the current window with focus is using xwayland. I can't see anything set in the global shortcuts system settings for this key so I don't believe it's being overridden.

@TRPB TRPB added the bug label Feb 21, 2021
@bk138
Copy link
Owner

bk138 commented Feb 21, 2021

Mh, seems KDE on Wayland needs something similar as 6501486 was for GNOME...

@bk138
Copy link
Owner

bk138 commented Feb 21, 2021

Found this (10y old :-/), there is a kwriteconfig utility that might be useful, but could not find any API so far. Some script example here.

@TRPB
Copy link
Author

TRPB commented Feb 21, 2021

Edit: I should have read the readme.

It looks like I can manually configure the keys as a workaround. I just need to manually bind the keys in KDE's system settings to gromit-mpx's functionality. While not ideal, at least I can still use this great tool on wayland.

edit2: the only problem remaining is that the gromit-mpx overlay blocks clicks. On Xorg, I can click through the overlay to interact with the applications behind the drawing

@bk138
Copy link
Owner

bk138 commented Feb 21, 2021

If you could come up with kwriteconfig commands to set/unset key bindings, that'd help a lot!

For the second, click-through, issue, please open a separate report.

@bk138 bk138 added this to the Release 1.5 milestone Feb 24, 2021
@Kadagaden
Copy link

I can confirm this and I use Sway, not KDE. Shortcut keys only work on xwayland windows (e.g. leafpad), and they don't work on the wayland windows (e.g. firefox, or foot terminal emulator). I can draw on wayland windows only if I start gromit-mpx then I use the command line for toggle, clear, etc. (But then I can't click on the workspaces and other stuff on swaybar, gromit-mpx has an overlay.)

Arch Linux
gromit-mpx-git: 1.4.r38.g1920bc1-1
wayland: 1.19.0-1
sway: 1:1.5.1-2

@bk138
Copy link
Owner

bk138 commented Apr 3, 2021

I can confirm this and I use Sway, not KDE. Shortcut keys only work on xwayland windows (e.g. leafpad), and they don't work on the wayland windows (e.g. firefox, or foot terminal emulator). I can draw on wayland windows only if I start gromit-mpx then I use the command line for toggle, clear, etc. (But then I can't click on the workspaces and other stuff on swaybar, gromit-mpx has an overlay.)

Arch Linux
gromit-mpx-git: 1.4.r38.g1920bc1-1
wayland: 1.19.0-1
sway: 1:1.5.1-2

@Ka-hu Please open another issue for Sway as the shortcut keys have to be implemented for each window manager/compositor specifically.

@bk138
Copy link
Owner

bk138 commented Feb 4, 2022

Until flatpak/xdg-desktop-portal#624 adds some cross-platform way of doing this, additional code handling desktop-environment-specific cases in add_hotkeys_to_compositor() and remove_hotkeys_from_compositor() is needed.

Pull requests welcome!

@bk138
Copy link
Owner

bk138 commented Feb 4, 2022

edit2: the only problem remaining is that the gromit-mpx overlay blocks clicks. On Xorg, I can click through the overlay to interact with the applications behind the drawing

@TRPB FYI that was #136 which is now fixed.

@ericschdt
Copy link

ericschdt commented May 21, 2022

edit2: the only problem remaining is that the gromit-mpx overlay blocks clicks. On Xorg, I can click through the overlay to interact with the applications behind the drawing

@TRPB FYI that was #136 which is now fixed.

In which version is this fixed? Edit: Looks like it's addressed in 1.4.2

@bk138
Copy link
Owner

bk138 commented May 21, 2022

edit2: the only problem remaining is that the gromit-mpx overlay blocks clicks. On Xorg, I can click through the overlay to interact with the applications behind the drawing

@TRPB FYI that was #136 which is now fixed.

In which version is this fixed? Edit: Looks like it's addressed in 1.4.2

Correct. v1.4.2 has 8aa79fe

@godmar
Copy link
Contributor

godmar commented Aug 19, 2022

I am experiencing a similar problem on a fresh install of Ubuntu 22.04 using Gnome. I'm using v1.4.2 of gromit-mpx. This is on a Dell Latitude 9520 with an active pen.

Pressing F9 works when the following applications have focus:

  • Firefox
  • xev
  • xterm

It fails when the following applications have focus:

  • gnome-terminal
  • gnome-system-monitor
  • Gnome's file viewer
  • Gnome desktop

I'm not very experienced with Wayland, so I don't know if this is the same issue. I'd be happy to provide more information. Also, is there a work-around?

@bk138
Copy link
Owner

bk138 commented Aug 19, 2022

@godmar You're exactly seeing what this issue is about. Hotkeys are detected by X11 apps (Firefox, xev, xterm) and thus by the X server (XWayland) which can then tell Gromit-MPX. This does not work with wayland apps though, where only the compositor can intercept hotkeys. That what #121 (comment) is about.

@godmar
Copy link
Contributor

godmar commented Aug 19, 2022

Got it. So this is not specific to KDE and the issue occurs when using GNOME as well. This comment was confusing in this respect.

@bk138
Copy link
Owner

bk138 commented Aug 19, 2022

Got it. So this is not specific to KDE and the issue occurs when using GNOME as well. This comment was confusing in this respect.

Yeah, that links the workaround, which was for GNOME only.

@godmar
Copy link
Contributor

godmar commented Aug 19, 2022

I don't understand. Is commit 6501486 supposed to address the problem in Gnome? Is this commit part of v1.4.2? If so, why does it not work for me as I run v1.4.2?

PS: as a side note, for me at least, the issue seems more complex. Even when I focus an X11 application before hitting F9, things will not work reliably. I've observed the focus "getting stuck" on a different window (requiring manual Alt-Tab and killing gromit-mpx), and I've observed Wayland windows (gnome-terminal) being left in a state where they are unable to receive keyboard input, even after gromit-mpx has been killed.

@godmar
Copy link
Contributor

godmar commented Aug 19, 2022

PS: for anyone wondering. 6501486 checks for whether XDG_CURRENT_DESKTOP is equal to GNOME. On Ubuntu 22, the value of this environment variable is however ubuntu:GNOME, so this test will fail.

However, the problem persists even when run with env XDG_CURRENT_DESKTOP=GNOME gromit-mpx/build/gromit-mpx -d so whatever this fix did, it doesn't work on Ubuntu 22.04's version of GNOME.

@bk138
Copy link
Owner

bk138 commented Aug 19, 2022

PS: for anyone wondering. 6501486 checks for whether XDG_CURRENT_DESKTOP is equal to GNOME. On Ubuntu 22, the value of this environment variable is however ubuntu:GNOME, so this test will fail.

However, the problem persists even when run with env XDG_CURRENT_DESKTOP=GNOME gromit-mpx/build/gromit-mpx -d so whatever this fix did, it doesn't work on Ubuntu 22.04's version of GNOME.

@godmar would you be so kind and open a separate bug report for this? You can also post Gromit-MPX's debug output there.

@bk138
Copy link
Owner

bk138 commented Sep 22, 2022

flatpak/xdg-desktop-portal#624 might help, at least for flatpaks and xdg-desktop-portal v1.16.

@bk138
Copy link
Owner

bk138 commented Oct 22, 2023

flatpak/xdg-desktop-portal#624 might help, at least for flatpaks and xdg-desktop-portal v1.16.

xdg-desktop-portal-kde has implemented this in https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/f0e3102c9a4e5930cc60fb001bae44289195b771 which apparently is in 5.27.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants