Open Fleimi opened 1 year ago
Can confirm, I have a feeling we're missing something similar to this commit where the fullscreen container isn't handing over the cursor to any shell-layers on top of it
should be fixed with 1e526411b6207349f1ea0341ab3319ff880a898d
can confirm, thanks for the fix!
unrelated issue that just popped up: inputs lock up and aren't passed to games even if no shell layer is active... unless mangohud counts as a shell layer. I'll report in a moment when I test that.
EDIT: Still locks up with mangohud disabled
Confirmed it doesn't happen without that commit, both with and without mangohud
what app? I can't repro, seemed to work fine.
Quake Champions for me, I can test it out in another game if need be as well
reverted the commit, will investigate more
Can confirm, with the commit keyboard input stopped working for FFXIV entirely, and conversely mouse input was perma-locked to FFXIV even after switching workspaces. Windowed/fullscreen didn't seem to make a difference
This is still an issue, happens to me in some games. for instance in valheim running natively it works, but only in the menus, if you're actually playing slurp will not allow you to select.
Slurp seems to be unable to select an area inside of most games I've tried.
For example, in Final Fantasy XIV, calling
grim -g "$(slurp -w 0)" - | wl-copy
whitens the screen indicating a selection is taking place, but clicking and dragging inside the game doesn't select anything and the selection mode doesn't end. Moreover, trying the pressEscape
to cancel the selection also doesn't do anything. The only way to back out of the selection is to switch to another workspace and pressEscape
or select an area as normal and make a successful selection/screenshot.I tried with Sway, working as intended. I tried with
windowrule=nofocus,title:(FINAL FANTASY XIV)
, and while this results in working Slurp selection, it also results in an un-interactable game window and as such is not a working fix in the end.