gromit-mpx icon indicating copy to clipboard operation
gromit-mpx copied to clipboard

Published 20 hours ago • verified publisher icon bk138

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

Open TRPB opened this issue 4 years ago • 20 comments

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 avatar Feb 21 '21 13:02 TRPB

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

bk138 avatar Feb 21 '21 15:02 bk138

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.

bk138 avatar Feb 21 '21 15:02 bk138

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

TRPB avatar Feb 21 '21 15:02 TRPB

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 avatar Feb 21 '21 16:02 bk138

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

Kadagaden avatar Apr 03 '21 06:04 Kadagaden

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 avatar Apr 03 '21 07:04 bk138

Until https://github.com/flatpak/xdg-desktop-portal/issues/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 avatar Feb 04 '22 13:02 bk138

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.

bk138 avatar Feb 04 '22 13:02 bk138

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

ericschdt avatar May 21 '22 17:05 ericschdt

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 8aa79feaa70a48d8161f1e5b6f741224373908f0

bk138 avatar May 21 '22 18:05 bk138

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?

godmar avatar Aug 19 '22 11:08 godmar

@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 https://github.com/bk138/gromit-mpx/issues/121#issuecomment-782871995 is about.

bk138 avatar Aug 19 '22 11:08 bk138

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.

godmar avatar Aug 19 '22 11:08 godmar

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.

bk138 avatar Aug 19 '22 11:08 bk138

I don't understand. Is commit 6501486d 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 avatar Aug 19 '22 12:08 godmar

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 avatar Aug 19 '22 14:08 godmar

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 avatar Aug 19 '22 14:08 bk138

https://github.com/flatpak/xdg-desktop-portal/issues/624 might help, at least for flatpaks and xdg-desktop-portal v1.16.

bk138 avatar Sep 22 '22 16:09 bk138

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

bk138 avatar Oct 22 '23 19:10 bk138