[ray023]

I also have no ideas how it works, but my guess would be that is actually translates exactly like that into games. Why would the mouse on the desktop have a latency that games do not have. Linux does not have a real fullscreen mode like Windows has (that I do not use anymore anyway for faster alt-tabbing). So my guess is, the cursor or mouse input gets into games very much the same way as it gets in the desktop.

[zamalek]

Wayland has support for games completely taking over the GPU; notoriously critical for VR support. This is basically the same as Windows exclusive full screen.

Wine/proton would need to support it, XWayland would need to support it (Wine/Proton are one major step away from native Wayland support: Vulkan), and finally the compositor would need to support it. Gnome is about the worst compositor that you could be testing any of this stuff on, they are comically hostile towards ideas not their own. The chances of this ever working on Gnome are near zero. KDE is pretty good for support, Hyprland seems to be trying to support every under the sun.

[debugnik]

> notoriously critical for VR support. This is basically the same as Windows exclusive full screen.

D3D12 dropped support for exclusive fullscreen, and I don't think headsets even go through DXGI but their own swap chain APIs. Why do VR games on Linux need the equivalent from the Wayland compositor?

[NekkoDroid]

> Gnome is about the worst compositor that you could be testing any of this stuff on, they are comically hostile towards ideas not their own. The chances of this ever working on Gnome are near zero.

GNOME has supported direct scanout for fullscreen apps for a while and drm-lease was implemented not too long ago either.

[ray023]

Did not know Wayland has exclusive FS.

[gsich]

Hardware cursor might be used in games. You notice the difference on Windows if a GPU does not support it, even on the desktop.