Hide Forgot
Created attachment 1767172 [details] Brief video of the behavior. This is a weird one, and I'm not entirely sure whether I should report this against `gnome-shell`, upstream, or xwayland. If somebody more knowledgeable than me thinks an xref is in order certainly let me know. This issue is only present on wayland. Description of problem: Switching between full screen X-Wayland Games and other windows causes issues with cursor. I have tested this on several OGL and Vulkan games. There are workarounds, but they are very annoying. I will try to attach videos to better explain the issue. Version-Release number of selected component (if applicable): gnome-shell-40.0-1.fc34.x86_64 xorg-x11-server-Xwayland-21.1.0-1.fc34.x86_64 Games tested: RPMs: supertuxkart-1.2-1.fc34.x86_64 Flatpaks: SuperTuxKart - A 3D arcade racer with a variety of characters, tracks, and modes to play. ID: net.supertuxkart.SuperTuxKart Ref: app/net.supertuxkart.SuperTuxKart/x86_64/stable Arch: x86_64 Branch: stable Version: 1.2 License: GPL-3.0+ Origin: flathub Collection: org.flathub.Stable Installation: system Installed: 689.7 MB Runtime: org.freedesktop.Platform/x86_64/20.08 Sdk: org.freedesktop.Sdk/x86_64/20.08 Commit: ee356193ac1e298dbf36871127865de1ba07b3e7ccc56563de34839d4906c149 Parent: 326a2f8327f2c1befc4397155b65d545c146efd58e1bb2f9fb7a8c2cfe6cf31f Subject: freedesktop runtime 20.08 (3230931c) Date: 2020-10-07 11:37:40 +0000 Steam - Manage and play games distributed by Steam ID: com.valvesoftware.Steam Ref: app/com.valvesoftware.Steam/x86_64/stable Arch: x86_64 Branch: stable Version: 1.0.0.69 License: LicenseRef-proprietary Origin: flathub Collection: org.flathub.Stable Installation: system Installed: 40.6 MB Runtime: org.freedesktop.Platform/x86_64/20.08 Sdk: org.freedesktop.Sdk/x86_64/20.08 Commit: 0807f17d80be4225aeb24f5daf99d87d64679aaae3d0565a6ce2f87dacef50e8 Parent: eea136cd10794523af9d6a56a978f0f3204bb8e38f5cd6144c1512024d97c02e Subject: Use combined version/url pattern (66b14b38) Date: 2021-03-14 10:38:18 +0000 Lutris - Play all your games by Lutris ID: net.lutris.Lutris Ref: app/net.lutris.Lutris/x86_64/beta Arch: x86_64 Branch: beta Version: 0.5.8.3 License: GPL-3.0-or-later Origin: flathub-beta Collection: org.flathub.Beta Installation: system Installed: 81.4 MB Runtime: org.gnome.Platform/x86_64/3.38 Sdk: org.gnome.Sdk/x86_64/3.38 Commit: 89e7318032959cac69c1396689f49415954a5e0a950032e2cc07b557a7d45e19 Parent: 0514556586a541517a81090703d9c34b077e6314e1aab58ff1309886f657d8a1 Subject: Update lutris to v0.5.8.3 (808bce4d) Date: 2021-02-04 20:51:16 +0000 How reproducible: Always, but there are some quirks here and there (described). Steps to Reproduce: 1. Open a full-screen game that uses xwayland (most of them). 2. Try switching applications using the activities overview. 3. Switch back to the game. Actual results: The Mouse is completely unresponsive, but the keyboard works. Expected results: Simply switch back to the game without any issues. Additional info: This is difficult to describe in words, so I attached a video as well. I tested this on several native and non-native (Proton) games, Overwatch through Lutris, xonotic and STK. I also tested both the RPMs and flatpak which made no difference. There are a few workarounds. Depending on the game, alt-tab and/or alt-enter may fix it, but this can also cause some bugs in the games like having to manually switch it back to full screen. I used the alt-tab work around for STK in my video.
I have done extensive testing and cannot find any solution or any cause. I'm cc'ing Xwayland maintainer for their input as well. Furthermore, I'll be open for needinfo/testing for the rest of this weekend.
If this affects fullscreen games only, chances are this could be an issue with mutter.
If you closely look at the video, the scrolling at the bottom of the game window stops as soon as the game is fullscreen, so I reckon the problem is not with input, but rather with repainting of the surface. Can you try to disable unredirection in mutter and see if the issue still occurs: * Type Alt+F2 * In the dialog type "lg" (without the quotes) to open Looking Glass * Type "Meta.disable_unredirect_for_display(global.display)" (without the quotes) and press Enter * Press Escape to exit Looking Glass Then see if that helps with the issue.
(In reply to Olivier Fourdan from comment #3) > If you closely look at the video, the scrolling at the bottom of the game > window stops as soon as the game is fullscreen, so I reckon the problem is > not with input, but rather with repainting of the surface. > > Can you try to disable unredirection in mutter and see if the issue still > occurs: > > * Type Alt+F2 > * In the dialog type "lg" (without the quotes) to open Looking Glass > * Type "Meta.disable_unredirect_for_display(global.display)" (without the > quotes) and press Enter > * Press Escape to exit Looking Glass > > Then see if that helps with the issue. This fixed it, but brings a few questions to mind: 1. Should I move this over to the mutter component (RHBZ and/or upstream)? 2. I'm guessing "unredirect" is referring to this: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/798. The compositor always seems to (and always has been for as long as I have used GNOME 3 on wayland) continue in games (i.e. even with vsync disabled and full-screen set I still see no tearing indicating there is a compositor action somewhere.) Could this be a bigger issue, or am I misunderstanding. 3. How do I/should I turn it back on? Performance seems about the same, but it is hard to tell without switching between the two (unless it shouldn't affect performance in which case I guess I'll just leave it; again, this concept is a little new to me.)
RE; 3. it is simply `Meta.enable_unredirect_for_display(global.display)` 😅 I will do further testing when I get a chance later today.
(In reply to Andrew Thurman from comment #4) > This fixed it, but brings a few questions to mind: > > 1. Should I move this over to the mutter component (RHBZ and/or upstream)? Yes, I believe this is an issue with mutter. > 2. I'm guessing "unredirect" is referring to this: > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/798. The compositor > always seems to (and always has been for as long as I have used GNOME 3 on > wayland) continue in games (i.e. even with vsync disabled and full-screen > set I still see no tearing indicating there is a compositor action > somewhere.) Could this be a bigger issue, or am I misunderstanding. Sorry I do not understand your question, a compositor is not required to avoid tearing if the client itself knows when to repaint (as with GL) > 3. How do I/should I turn it back on? Performance seems about the same, but > it is hard to tell without switching between the two (unless it shouldn't > affect performance in which case I guess I'll just leave it; again, this > concept is a little new to me.) Those changes are not permanent, if you restart your session they will be lost. Alternatively you could use the same procedure with "Meta.meta_enable_unredirect_for_display(global.display)" - But this is for testing purpose only, ideally, the bug should be fixed instead.
Alright, thanks. I have work to do soon, but afterward I will try and do some further testing. I also believe I talked to someone on IRC having the same issue, so I will try and get their input and anyone else in the Fedora Gaming community experiencing the issue as well. Furthermore, I will also try and test an upstream build of mutter to see if the issue should be opened there as well.
(In reply to Andrew Thurman from comment #7) > […]Furthermore, I will also try and test an upstream build of mutter > to see if the issue should be opened there as well. https://gitlab.gnome.org/GNOME/mutter/-/issues/1636 might be relevant.
(In reply to Olivier Fourdan from comment #8) > (In reply to Andrew Thurman from comment #7) > > […]Furthermore, I will also try and test an upstream build of mutter > > to see if the issue should be opened there as well. > > https://gitlab.gnome.org/GNOME/mutter/-/issues/1636 might be relevant. Possibly, but I had no such issue in 3.38. This also sometimes seems unreproduceable where mine is always. Also possible duplicate: https://bugzilla.redhat.com/show_bug.cgi?id=1945952
Also, I'm not sure the screen capture fully puts into perspective what is happening. I'm going to try an external capture device (my smartphone camera) and see if that makes it a little clearer.
[ Reporter of that upstream issue here ] (In reply to Andrew Thurman from comment #9) > Possibly, but I had no such issue in 3.38. Maybe it didn't happen as often with 3.38. > This also sometimes seems unreproduceable where mine is always. It's reproducible for me with some apps, in particular with Assetto Corsa Competizione. I just don't have that installed on the laptop where I wrote the issue, and I had trouble finding another reliable reproducer there; I ended up mentioning the Steam Big Picture UI, where it's not 100% reproducible for me.
> Can you try to disable unredirection in mutter and see if the issue still occurs: > * Type Alt+F2 > * In the dialog type "lg" (without the quotes) to open Looking Glass > * Type "Meta.disable_unredirect_for_display(global.display)" (without the quotes) and press Enter > * Press Escape to exit Looking Glass > Then see if that helps with the issue. Does this solve your issue? I will also add steam big picture to my testing later today.
Maybe you're hitting https://gitlab.gnome.org/GNOME/mutter/-/issues/1699 instead?
(In reply to Michel Dänzer from comment #13) > Maybe you're hitting https://gitlab.gnome.org/GNOME/mutter/-/issues/1699 > instead? I think that may be exactly it! I'll also test that MR.
(In reply to Michel Dänzer from comment #13) > Maybe you're hitting https://gitlab.gnome.org/GNOME/mutter/-/issues/1699 > instead? Fixed! I created this PR: https://src.fedoraproject.org/rpms/mutter/pull-request/24 This is my first package PR, so please tell me if I did something wrong. Built locally successfully on F34, so I'm just going to keep that until this gets fixed. Thanks for the help.
After a little more testing I can say this isn't completely fixed, but it is *a lot* better. I still rarely have to tab in and out.
(In reply to Andrew Thurman from comment #16) > After a little more testing I can say this isn't completely fixed, but it is > *a lot* better. I still rarely have to tab in and out. I haven't noticed the cursor issues anymore with the upstream fix. I do still hit the drop to 1 fps described in https://gitlab.gnome.org/GNOME/mutter/-/issues/1636 (and bug 1945952 I assume), presumably that's a separate issue.
BTW, the attached video didn't properly capture the problem due to https://gitlab.gnome.org/GNOME/mutter/-/issues/1707 .
So, the only real issues I have right now are with overwatch. I did just a little testing, but borderless windowed instead of full-screen seems to fix it. I will try and do further testing, but I may not have time until this weekend,
(In reply to Andrew Thurman from comment #15) > (In reply to Michel Dänzer from comment #13) > > Maybe you're hitting https://gitlab.gnome.org/GNOME/mutter/-/issues/1699 > > instead? > > Fixed! > > I created this PR: https://src.fedoraproject.org/rpms/mutter/pull-request/24 > > This is my first package PR, so please tell me if I did something wrong. > > Built locally successfully on F34, so I'm just going to keep that until this > gets fixed. Thanks for the help. Has anyone taken a look at this? It is a pretty major bug to have well into the freeze. If I did something wrong, please let me know, but I'd really like for this patch to get pushed and not to have to rely on a local build.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.