Gamescope won't register mouse or keyboard input correctly

[nonetrix]

Hyprland Version

System/Version info

Hyprland, built from branch  at commit f8857e6072bd85b95393499688872aaf7f088b5b  ().
Date: 2024-05-18
Tag: , commits: 

flags: (if any)


System Information:
System name: Linux
Node name: nixos
Release: 6.9.1
Version: #1-NixOS SMP PREEMPT_DYNAMIC Fri May 17 10:18:09 UTC 2024


GPU information: 
09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] [1002:73bf] (rev c3) (prog-if 00 [VGA controller])


os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.05.20240517.4a6b83b"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.05 (Uakari)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.05 (Uakari)"
VERSION_CODENAME=uakari
VERSION_ID="24.05"


plugins:
  hyprsplit by shezdy ver 1.0

Bug or Regression?

Bug

Description

It seems Gamescope 3.14.15 is completely broken on recent versions of Hyprland, it won't take keyboard or mouse input whatsoever anymore. I suspect something got broken when rewriting something, or it might be a issue on Gamescopes side. It seemed to have started with Gamescope added CSDs which look terrible on Hyprland, I imagine GNOME can be fully to blame

How to reproduce

1. Open Hyprland
2. Open a game in Gamescope with gamescope $app
3. Try to do anything with mouse or keyboard
4. Doesn't work
5. Try in fullscreen
6. Also doesn't work
7. Really dumb keybinds such as meta + f to fullscreen don't work that in Valves infinite wisdom use meta and conflict

Crash reports, logs, images, videos

Video:
https://github.com/hyprwm/Hyprland/assets/45698918/ea9b01dc-22f1-42de-8fd6-824ab5595205

Running prismlauncher in Gamescope with WAYLAND_DEBUG=1 and trying to click next then closing:

https://gist.github.com/nonetrix/5b17027cdc551fc5d8d9c3e84ce48827

My configs in which this happens:
https://github.com/nonetrix/nixdots

[Atemo-C]

Perhaps related to these?

• Gamescope issue
• Hyprland issue

[nonetrix]

I am not using cursor capture, actually seems to make things slightly better. It will get the cursor position correctly now, but then it won't let me click or type

[nonetrix]

Here is it with cursor capture, half fixes it but still broken. I will keep this option in mind though might work around other issues. But does appear that the cursor lock is indeed broken since I can move it outside of the window, but this issue isn't related

out.mp4

[nonetrix]

Here is with cursor lock and WL_DEBUG=1
https://gist.github.com/nonetrix/d7370350f4e4e09802cbf9a37c172d44

[Agent00Ming]

can you get a log of this in sway?

[nonetrix]

Here is is!
https://gist.github.com/nonetrix/e03589d0f41571a580d59ac524b98e40
I also noticed a lot of differences weirdly in Sway. First, no CSDs at all, then it uses nearest neighbor scaling if it is low res, then finally the input works in Sway unlike Hyprland for now. I feel like somethings sus here

[nonetrix]

Just to be safe I checked the Gamescope source code and there is not mention of Sway, I was thinking maybe as for the CSD issue maybe it checks the name of the compositor and if it's unknown just enables CSDs to be safe? But no, but seems like unrelated issue likely best to get it working at all first

[Agent00Ming]

are you sure you tested it both on sway and hyprland in the same conditions (lock/no-lock, same program, etc)?

[nonetrix]

I used fullscreen with no cursor lock and it worked fine, same with windowed. I can try cursor lock if you would like

[nonetrix]

Sway (works in all 4 cases)

• Fullscreen cursor lock: https://gist.github.com/nonetrix/5c9fdb73f88ad6041b7b1e4f6f8e6a3f
• Fullscreen no cursor lock: https://gist.github.com/nonetrix/c5d78e089f0995cadeea19ff2b31d971
• Windowed cursor lock: https://gist.github.com/nonetrix/4a03da563fe32a2bc0af9515fb0c819d
• Windowed no cursor lock: https://gist.github.com/nonetrix/12c538e65986a100bb869ae0165c011a

Hyprland (fails in all 4 cases and had to close with key binding)

• Fullscreen cursor lock: https://gist.github.com/nonetrix/f343fc82b6690c491357fc15d0bfef9d
• Fullscreen no cursor lock: https://gist.github.com/nonetrix/8bf65bf957b3b130bd339973375e27e9
• Windowed no cursor lock: https://gist.github.com/nonetrix/caa6396c8a88e06c4988b4f12b91a218
• Windowed cursor lock: https://gist.github.com/nonetrix/ce7791c2fe32cce632d14fc0cd898272

[The-Briel-Deal]

Do you have a first known good and last known bad? If you can find what version is last working that would be super helpful to see what broke. It would also be nice to isolate hyprland as the variable.

[nonetrix]

I will downgrade a few commits and report back, going to Install Arch for easier testing like I said I was going to do at least 3 times

[nonetrix]

Just got done installing Arch, on version 0.40.0 issue is not there somewhat but there is issue where cursor is offset upwards unless fullscreened also CSD still there. I will try newer version until I get the bug

[nonetrix]

And yes able to reproduce on Arch with git version with bone stock config

[nonetrix]

I have bad and good news, good news I found the where the issue appeared... The bad news is that it was one of the rewrite commits so it's likely hard to find

121d3a7

The cursor offset and CSD bug was present in all versions I tested, since the CSD appear above where they should I feel like it is related to CSD perhaps? The offset seems about right. I am not sure why the CSD is present on Hyprland and not Sway to be honest, but if it is CSD we should at least get the CSD to work correctly then figure out why it's there and how to get the same behavior as in Sway

[The-Briel-Deal]

Update, I was able to repro with gamescope -W 1920 -H 1080 -r 60 -- supertuxkart with gamescope@3.14.3-1 and supertuxkart@1.4-5 from arch official repo, as well as hyprland@v0.40.0-112-ga7fc7f87.

I'm looking into this now. I'll try to have a PR up by tomorrow.

For me gamescope is totally in major janko mode as

1. While the window is open, there seems to be no updated frames or animations. (there is still audio, but it does not seem to respond to input)
2. It closes after my mouse leaves and enters the window a few times.
3. I get these warnings and errors:

[warn   ] SPMeshBuffer: kartDirt shader is missing, fallback to solid
[warn   ] SPMeshBuffer: kartDirt shader is missing, fallback to solid
[warn   ] SPMeshBuffer: kartDirt shader is missing, fallback to solid
[warn   ] SPMeshBuffer: kartDirt shader is missing, fallback to solid
[warn   ] SPMeshBuffer: kartDirt shader is missing, fallback to solid
xdg_backend: Changed refresh to: 59.997hz
xdg_backend: Changed refresh to: 120.000hz
xdg_backend: Changed refresh to: 59.997hz
xdg_backend: Changed refresh to: 120.000hz
gamescope: ../gamescope/src/wayland_backend.cpp:688: void gamescope::CWaylandFb::OnCompositorRelease(): Assertion `m_bCompositorAcquired' failed.
(EE) failed to read Wayland events: Connection reset by peer
fish: Job 1, 'gamescope -W 1920 -H 1080 -r 60…' terminated by signal SIGABRT (Abort)
⏎     

[nonetrix]

Tried running git version? I think that's a known issue already it crashing with focus change, was having it when I downgraded a few versions. I think that is fixed already, just everything else is broken

As for

[warn   ] SPMeshBuffer: kartDirt shader is missing, fallback to solid

What GPU are you using? That sounds like your GPU is old and doesn't support some hardware or driver feature. Actually, could also be a missing file or bug. kart makes me think it's Super Tux Kart as you mentioned which is the problem here, I am doubtful that is relevant. If you cannot fix that by force reinstalling Super Tux Kart or updating drivers or using different hardware, then search on their GitHub instead and report it if it doesn't exist I guess

[Agent00Ming]

The hyprland logs show that the motion data is rounded to nearest integer and no axis events are sent at all. The sway logs show axis events with no values ( only source + stop ?)

[vaxerski]

is gamescope binding wl_seat multiple times? if so, tell them to stop

[The-Briel-Deal]

Tried running git version? I think that's a known issue already it crashing with focus change, was having it when I downgraded a few versions. I think that is fixed already, just everything else is broken

As for

[warn   ] SPMeshBuffer: kartDirt shader is missing, fallback to solid

What GPU are you using? That sounds like your GPU is old and doesn't support some hardware or driver feature. Actually, could also be a missing file or bug. kart makes me think it's Super Tux Kart as you mentioned which is the problem here, I am doubtful that is relevant. If you cannot fix that by force reinstalling Super Tux Kart or updating drivers or using different hardware, then search on their GitHub instead and report it if it doesn't exist I guess

Sorry didn't have time to play with this any deeper yesterday. I'll try to make time in a bit.

As for the GPU I have its a 6900XT. I agree though, the shader warns are probably just supertuxkart. I just tried that because I don't have steam on this machine rn, and because supertuxkart was able to run without gamescope and its worked with gamescope in the past.

I'll look into the wl_seat binding thing when I get back to this vaxry. Just curious, is gamescope working for you guys?

[The-Briel-Deal]

Its also kind of whacky that the window has gnome/lib-adwaita window decorations?

Also, 1 more note, the mouse is working, its just very far offset. It looks like its treating the mouse like the window stretched sort of? But the window inside is being rendered without stretching or scaling.

[vaxerski]

hyprland does everything it can to hint it does NOT want CSD. If an app uses them regardless, blame the developers of the app. (re: decorations)

[The-Briel-Deal]

Did a bit of bisecting and testing but def not done yet. I just wanted to update with my findings to help anyone else messing with this.

1. Ran latest hyprland release as of 20 minutes ago from official arch repos with latest gamescope (with my latest config you can see in my dotfiles repo). Issue persisted with CSD issue.
2. Built 0.37.0 from the tagged release on git along with updating all of the submodules. I installed this built version and changed no variables.
   Issue persisted without the CSD issue (as in there was no csd as there shouldn't be).
3. Modified my config and ONLY changed my monitor scaling from 1.5->1 on both monitors. Everything worked as intended (as far as I was able to test).

To summarize:
Hyprland version seems to be the variable with the CSD issue afaik, I just know that it does work on 0.37.0 with nothing else changed. My scaling being 1.5 previously seems to a variable causing the mouse issue.

If I were to guess, this probably has something to do with disabling xwayland scaling (as I also have that on) along with having a non-0 or odd scale factor.

My next steps:
Verify my theory of the xwayland game window scaling different from the wayland gamescope window. (Gamescope outputs a wayland window, but runs its games in xwayland underneath if anyone didn't know)

Going to continue on this tomorrow. I haven't had quite as much time to mess with this as I would like the last few days. Please update this ticket if anyone else can verify my findings or add anything here! Thanks guys!

[nonetrix]

I should have mentioned in my issue that I have 2 monitors, one is 1920x1080 the other is 1920x1200. I will try disabling one tomorrow and see if anything happens I guess

[vaxerski]

would be nice to bisect the CSD too

[Agent00Ming]

I was replying to some other guy's comment about this issue

[nonetrix]

Sorry I misread

[nonetrix]

I should have mentioned in my issue that I have 2 monitors, one is 1920x1080 the other is 1920x1200. I will try disabling one tomorrow and see if anything happens I guess

Also, do you have scaling set? I would also be interested to hear if any games do work? I'm wondering if its a specific graphics library that's problematic as well. Pretty sure supertuxkart is opengl

It has nothing to do with the game, other applications and games have the same issue. But no, I do not have any scaling set just the defaults, I haven't had a need for scaling

[The-Briel-Deal]

Going to update this comment with bisect findings:

So far I know that the input/mouse issue is between 0.40.0-75@60be4298 and 0.40.0-91@3fe5280c. And the CSD issue is sometime before 0.40.0-75. Sorry my notes are a mess lol I am tired. Should find the real commit tomorrow and hopefully have a fix out.

Also Vaxry, I tested that big PR for wlroots that is going to be merged soon. That doesn't fix the issue in case you were wondering.

* Known Good: 0.39.0 at commit e93fbd7c4
* Known Good: 0.39.1 at commit fe7b748eb
* Known Good: 0.40.0-74 at commit 4c625ce9 May 13 CSD MAYBE GOOD HERE (I forgot to note)
* Known Good: 0.40.0-75 at commit 60be4298 May 13 WITH CSD ISSUE
* Known Bad: v0.40.0-88 at commit 31890026 May 15 WITH CSD ISSUE.
* Known Bad: v0.40.0-91 at commit 3fe5280c May 15 WITH CSD ISSUE
* Known Bad: 0.40.0-94 at commit 9eec4cb6 May 15 WITH CSD ISSUE

* Known Bad: 0.40.0-108 at commit 9518cec8 May 17
* Known Bad: 0.40.0-132 at commit 2ff95bba

* Maybe CSD commit 60be4298e13b02913f241dd79fe7517f185299d0?

* Current Suspected Input Issue Commit 31890026ea9f3ce75dbcfdf060239fc8aa6c144c

Also bonus finding, --force-grab-mouse makes the mouse sort of work even on broken lol.

[The-Briel-Deal]

I have bad and good news, good news I found the where the issue appeared... The bad news is that it was one of the rewrite commits so it's likely hard to find

121d3a7

The cursor offset and CSD bug was present in all versions I tested, since the CSD appear above where they should I feel like it is related to CSD perhaps? The offset seems about right. I am not sure why the CSD is present on Hyprland and not Sway to be honest, but if it is CSD we should at least get the CSD to work correctly then figure out why it's there and how to get the same behavior as in Sway

Lol, idk how I missed this...

Thanks for finding that! It seems like you're right, struggling to build the commit before to verify that the commit before was good but that definitely lines up with where I was going. It shouldn't be too bad, I just need to look through the commits in the PR that merged that commit.

#5999

Going to come back to this tomorrow though. Thanks for finding that!

[The-Briel-Deal]

One more update on findings:
Mouse events make it to Line 228 of SeatManager.cpp in sendPointerButton() and Line 618 of
InputManager.cpp in processMouseDownNormal() and I get a message saying "Unsupported
maximum keycode 708, clipping. X11 cannot support keycodes above 255." when starting gamescope. Also, the keycodes that are being sent for right and left mouse button are 272 and 273.

This makes me wonder if the keycodes from InputManager are being clipped because they are too high? Still haven't figured out what changed that would cause that in the commit but it seems like that might be a possible culprit.

[The-Briel-Deal]

I'm sort of blocked on this right now, sort hoping that this somehow gets fixed in the next wlroots rewrite PR.

That said, for anyone who wants to take a stab at this. You can easily reproduce this with:

gamescope -- xev

You will notice pretty much no input events come through except for one mouse move event when entering the window.

[vaxerski]

should be fixed.

[nonetrix]

Yep completely fixed for me now, works same as Sway now. No CSD, no offset, cursor works everything

[nonetrix]

So was it a Gamescope issue somewhat in the end? The commit message seems to suggest that, in that case I guess I should make a issue on Gamescope too so we can also fix the bad behavior at the root. But good that it fixes some dumb apps

Still having some weird behavior in Gamescope though, like it seems to lag more than usual and I get the following a lot

xwm: got the same buffer committed twice, ignoring.
xwm: got the same buffer committed twice, ignoring.
xwm: got the same buffer committed twice, ignoring.
xwm: got the same buffer committed twice, ignoring.
xwm: got the same buffer committed twice, ignoring.
xwm: got the same buffer committed twice, ignoring.
xwm: got the same buffer committed twice, ignoring.

Then

xdg_backend: Changed refresh to: 59.950hz
xdg_backend: Changed refresh to: 164.917hz
xdg_backend: Changed refresh to: 59.950hz
xdg_backend: Changed refresh to: 164.917hz
xdg_backend: Changed refresh to: 59.950hz
xdg_backend: Changed refresh to: 164.917hz
xdg_backend: Changed refresh to: 59.950hz
xdg_backend: Changed refresh to: 164.917hz

Is spammed constantly even though I not switching monitors

Then this seems like it should be solid black and seems to be making my whole desktop have a seizure

I will see if this happens on Sway later but seems odd

[The-Briel-Deal]

Yea, I've noticed the refresh rate messages too. I kind of just chalked that up to a red herring.

My guess with those messages is that they are due to me having two different refresh rates for each monitor.

The messages swapped between 60 and 120 for me. And thats the rr of my monitors. Curious if thats the same for you?

[nonetrix]

Yes it is likely separate issue

[vaxerski]

So was it a Gamescope issue somewhat in the end? The commit message seems to suggest that

it is technically allowed by spec to bind wl_seat many times, but IMO it's stupid. The events should be duplicated over all the bound seat resources which makes little sense.

[nonetrix]

Well still worth pointing out perhaps if it is unintended I guess and likely not ideal, good to follow spec still I'd say just for compatibility even if it's disagreeable. It would be a overstatement to call me a developer, but does seem dumb to me as well if I understand it. Is wl_seat like a listener or something that listens for events such as keyboard etc. And it's making multiple instances and expects it to be sent to all? I feel like that would result in duplicated key presses so I think I'm completely misunderstanding fundamentally probably

[nonetrix]

Aaaaaand Gamescope is broken yet again in a new way, I am now measuring frames in minutes. Everything else seems fine but it's even more laggy with #6268

I guess I should make a new issue for this and other issues as well

[leiserfg]

I'm on 1423707 and I still have some issues with gamescope, keyboard events work fine but the mouse events are misplaced, looks like the coords are multiplied 'cause they are kinda fine in the left-top corner but are like half screen off in the right corners.

[nlfog]

I'm on 1423707 and I still have some issues with gamescope, keyboard events work fine but the mouse events are misplaced, looks like the coords are multiplied 'cause they are kinda fine in the left-top corner but are like half screen off in the right corners.

I came across this comment on a google search, I just started having this same issue today, but I don't use Hyprland and my gamescope version if from April (Nobara gamescope-3.14.11-4.git.20240430.c7ef7c4.fc39.x86_64). When I try Guild Wars 2, I can easily click the settings menu in the top left corner, but the further I move away, the further the mouse clicks register. Very strange!

[misyltoad]

it is technically allowed by spec to bind wl_seat many times, but IMO it's stupid. The events should be duplicated over all the bound seat resources which makes little sense.

We have a dedicated input thread, the backend code's main Wayland queue is only polled, potentially once per frame/refresh cycle, the input thread has it's own separate queue and is waited (epoll) upon and is constantly forwarding events ASAP to the app running in Gamescope.

It's not really nice to call that "legitimately braindead" or "stupid", it's incredibly normal app design.

Many modern video games have a dedicated input thread doing basically the same thing.

FTR, I don't care about key or motion events on the main thread at all, but unfortunately I have to register for them all if I want enter/leave, Wayland design moment. I can't just pass the state around because I need the wl_keyboard objects and wl_pointer objects on the main thread for stuff which means the compositor is going to send the events anyway.

[vaxerski]

Excuse my tone, maybe it's been a bit overboard, but it still doesn't make much sense to me - it would make much more sense to bind wl_seat once and internally forward the events instead of binding the main compositor's wl_seat 4 times

[misyltoad]

No, it's only bound twice. You can check this with WAYLAND_DEBUG or breaking on wl_registry_bind/wl_seat_add_listener.

[vaxerski]

dunno man

(taken from #6159 (comment))

[shogeki]

I have found that downgrading to gamescope 3.14.2 fixes this for me (3.14.3 is broken)

[misyltoad]

@vaxerski You know XWayland and other clients bind seats of Gamescope (ie. not Hyprland) right?

You have to exclude clients lmao.

[vaxerski]

oh, my bad. I am dumb.