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

[BUG] doesn't receive keypresses (Plasma/Xwayland) #2030

Open
2 tasks done
j12i opened this issue Sep 18, 2024 · 3 comments
Open
2 tasks done

[BUG] doesn't receive keypresses (Plasma/Xwayland) #2030

j12i opened this issue Sep 18, 2024 · 3 comments
Labels

Comments

@j12i
Copy link

j12i commented Sep 18, 2024

Rofi version (rofi -v)

Version: 1.7.5

Configuration

https://gist.github.com/j12i/ecfd1c92e9d413a6ab2fb71b9dee8a5b

Theme

https://gist.github.com/j12i/1224d9df6c196c4025eab19cd4b4a364

Timing report

No response

Launch command

rofi -dmenu -i

Step to reproduce

I have a shell script that calls rofi in ~/bin/. This script is called with a keyboard shortcut set up with Plasma system settings. To reproduce just press the keyboard shortcut on an empty desktop.

Expected behavior

I can type and rofi narrows the given list.

Actual behavior

My keypresses go "nowhere" for Plasma seemingly, so it opens KRunner and my input goes there.

Additional information

Yes, I use Wayland, and I read #446 and the wiki page. I was hoping maybe this bug could be addressed on the XWayland side without getting into native Wayland support. Or that this is actually a Plasma bug that I can report there.

It only happens when no other window is visible on the desktop (they can be minimized, or just that there isn't anything open). As long as any other window is visible, the keypresses go into rofi as expected.

System versions:
Linux 5.15.161
Slackware64 15.0
Plasma 5.23.5
Wayland 1.22.0
Xwayland 21.1.4
plasma-wayland-protocols-1.6.0
kwayland-5.90.0

Using wayland display server protocol

  • No, I don't use the wayland display server protocol

I've checked if the issue exists in the latest stable release

  • Yes, I have checked the problem exists in the latest stable version
@j12i j12i added the bug label Sep 18, 2024
@DaveDavenport
Copy link
Collaborator

I think this is not a rofi bug, it looks like (but not sure with this information) that rofi is not allowed to grab the keyboard on an empty desktop.
I have no idea how this is handled in Xwayland/wayland/etc.

If somebody with more knowledge can look into this? but I don't run wayland or Xwayland and have no way to debug.

I strongly recommend using @lbonn his wayland port of rofi if you use wayland.

@j12i
Copy link
Author

j12i commented Sep 18, 2024

Thank you @DaveDavenport.

I would like to try @lbonn's port but your version is packaged for my distro (https://slackbuilds.org/repository/15.0/desktop/rofi/ – this repo is similar to Arch's AUR) and the port uses a different build system. I'll take a stab at it now but I don't have a much energy to spend on it.

ETA: Oh well, I didn't get far.

Dependency glib-2.0 found: NO found 2.70.3 but need: '>= 2.72'

@lbonn
Copy link
Collaborator

lbonn commented Sep 18, 2024

@j12i we also have this issue open on the wayland fork lbonn#121 but you seem to be running mainline rofi.
rofi on XWayland has issues that cannot really be worked around I am afraid.

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

No branches or pull requests

3 participants