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] Weird interaction with swaybar mode=hide #161

Open
2 tasks done
fenneltheloon opened this issue Dec 7, 2024 · 3 comments
Open
2 tasks done

[BUG] Weird interaction with swaybar mode=hide #161

fenneltheloon opened this issue Dec 7, 2024 · 3 comments
Labels

Comments

@fenneltheloon
Copy link

Rofi version (rofi -v or git commit in case of build issue)

1.7.5

Configuration

https://gist.github.com/fenneltheloon/9355418fe0e1af78394951bef74ecaa8

Theme

https://gist.github.com/fenneltheloon/008de6bad7163bc91b0436c5ffaa3d6f

Timing report

No response

Launch command

rofi -show drun

Step to reproduce

I have a multi-monitor setup, there is always a single of the three monitors that has this issue.

While running Sway, set bar mode to hide
Launch rofi

Expected behavior

Expect rofi to capture all input while onscreen

Actual behavior

Regardless of swaybar location or rofi location (north/south of screen), rofi will fail to capture keyboard input unless mouse cursor is inside the window on single monitor specifically. Keyboard input will instead go to the window underneath the mouse cursor. Current problematic output is DP-1, changed a monitor setting and it moved to DP-3 (a different monitor), then rebooted and is back to the original device. I swapped the displayport cables to see if it had to do with numbering and the same physical device presented with the issue (swapping physical devices DP-1 and DP-3 did not change which actual monitor was having the issue). If I run rofi out of a terminal located in a workspace in the problematic output, the issue is not present.

Additional information

It seems like this might be a display configuration issue, but I'm not sure what to do about that. Here's the relevant part of the sway config?

output DP-3 mode [email protected] position 0 0
output DP-1 mode [email protected] position 2560 0
output HDMI-A-1 mode 1920x1080@60Hz position 5120 360
output * max_render_time off

Using wayland display server protocol

  • Yes, I use rofi with wayland support

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

  • Yes, I have checked the problem exists in the latest stable version
@lbonn
Copy link
Owner

lbonn commented Dec 8, 2024

@fenneltheloon

Rofi version (rofi -v or git commit in case of build issue)

1.7.5

Is this the full version string? Because in this case it would be mainline rofi.
Example of a wayland rofi version:

$ rofi -v
Version: 1.7.5+wayland3-51-g0a0cc5f6

@fenneltheloon
Copy link
Author

fenneltheloon commented Dec 8, 2024

pacman reports 1.7.5+wayland3-2!

@fenneltheloon
Copy link
Author

If I hover over the menu and then back off on the affected monitor, the focus remains captured by rofi.

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

2 participants