8 ms·

Playing fast FPS games under wayland/xwayland (and under Gnome/gnome-shell/mutter) is currently suboptimal. It's because gnome-shell will pass mouse moves only

by jagrsw 5y ago

Playing fast FPS games under wayland/xwayland (and under Gnome/gnome-shell/mutter) is currently suboptimal. It's because gnome-shell will pass mouse moves only at the speed of your monitor refresh rate (see https://blogs.gnome.org/shell-dev/2021/12/08/an-eventful-instant/ https://blogs.gnome.org/shell-dev/2021/12/08/an-eventful-ins... for the explanation) I have a 240Hz monitor, so gnome-shell passes data to xwayland and then to applications at ~220Hz (as seen in the event-freq from https://blogs.gnome.org/shell-dev/2021/12/08/an-eventful-instant/ https://blogs.gnome.org/shell-dev/2021/12/08/an-eventful-ins...) So, my expensivish 1kHz (or even 8kHz mice - as these exist) will pass mouse movements with 4ms+ delay and only <240 times per second. Under Xorg, the xinput proto will pass data at the ~usb polling speed. For my 2kHz mouse, the tool (event-freq) shows ~1700 events / second. By the way, this ~220Hz is the speed at which gnome-shell passes data to clients (via XWayland or directly). The libinput accepts and passes data at correct 2kHz - and it's only gnome-shell aggregates it under wayland - this can be seen e.g. in the evhz tool (direct /dev/input access) vs event-freq tool (gnome-shell in wayland session, and xinput in xorg session).

GhettoComputers 5y ago
Damn, I thought gamers would find it useful. What is wayland even good for?
- kevingadd 5y ago
  For crashing your games if you move the mouse too fast https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
  - GhettoComputers 5y ago
    Thanks, now I know for sure the steam deck will just be another windows computer that came with linux. Even these assumptions about its use case were wrong. How could anyone in good conscious support switching to this? I can see noobs who think newer is better, but wow, horrid. Android is pretty smooth, I wonder if running the framework of it on linux could work lol.
    - 1_player 5y ago
      > now I know for sure the steam deck will just be another windows computer that came with linux Your "This Linux tech is pretty shit isn't it" posturing you've shown all over this thread and other Linux posts is _insufferable_. We don't need novelty accounts to repeat the same trite cynicisms everywhere, there's Reddit for that.
      - GhettoComputers 5y ago
        Feel free to leave the thread because you can’t handle these truthes. Wayland by itself is complete shit and will be enough to ruin the deck experience.
- jagrsw 5y ago
  Having two monitors with different DPI or physical size. Wayland supports different scaling per monitor, so your windows will look thesameish in terms of physical or pixel size (depending on your wishes) when moving them across monitors :).
  - badsectoracula 5y ago
    There isn't really a reason for this to not be done on Xorg too, aside from having the window manager keep track of per-monitor scaling information (note that scaling, physical size and DPI do not have to be tied - someone may want to use a big scale for a low DPI monitor because they have it across the room for example, what really matters is a per-monitor scaling factor - DPI can be used to set up some sane defaults but this should be overridable) and pass it to applications to scale themselves with a fallback if the application doesn't support scaling (be it client-side composition or server-side composition, though the latter will also need merging Keith Packard's patch that implements composition-based server side window scaling)... and someone to specify the messages/events involved. But really almost all the tech exists (aside from server side scaling, but this can be ignored for an initial implementation) and toolkits (or at least Qt and perhaps Gtk) should already support this as Windows scaling works in a similar way, it is largely getting a bunch of different projects to play nice together.
    - jagrsw 5y ago
      I think Qt supports it in some quirky way. It supports this DPI notation of something like QT_DPI="192;128" via envvars. But it only means that when moving window to another monitor the window will get suddenly re-scaled/re-sized, instead of being smoothly drawn using different scaling factor.
      - badsectoracula 5y ago
        Well, yes, this is basically all what applications can do by themselves without support from the rest of the stack. It isn't impossible but it will be limited to application/library-specific hacks and those have a limited view of the system anyway. Ideally you want support from the environment itself and applications only be responsible for scaling themselves properly. The window manager is at the best position to support something like this since it handles window placement. It is possible to have a separate program that can keep track of window placement and support the relevant events too (for window managers that wont support this) but it can be tricky to get it work smoothly. The sudden scale/resize is something that can't really be avoided without support from the compositor (be it the window manager, a separate compositor or server-side composition), assuming there is one of course (this should work without a compositor too, you'd just wont get the scaled fallback unless the server-side scaling patch is also added to Xorg). Again, can be done and the tech is there, it just needs wiring all these things up.
- zamadatix 5y ago
  Mixed refresh rate monitors.
  - pantalaimon 5y ago
    This works on X11
    - zamadatix 5y ago
      If you don't have a syncing compositor which is a bit of a limitation.
- nicce 5y ago
  This is more about Gnome’s Mutter implementation problem, not directly problem of Wayland. There are other compositors
  - badsectoracula 5y ago
    One issue with these "other compositors" is that you aren't just replacing the compositor itself but you have to replace the entire environment.
  - GhettoComputers 5y ago
    What compositor should be used? Never heard x.org doesn't have this problem with any.
    - jagrsw 5y ago
      I'm not an expert on the wayland/xorg/xinput/gnome-shell stack, but unless someone smarter takes good measurements of various things (visual and input delays), I'd suggest 1). Xorg + gnome-flashback or Xorg + other non-compositing WM or 2). Non-gnome compositor under wayland As for 1). Xorg b/c it can provide pointer movements at ~native speed via xnput vs Gnome/Wayland 60-240Hz. And gnome-flashback b/c it's a non-compositing WM, so there's no frame buffering (unless you enable it in nvidia's panel, or via TearFree in amdgpu). As for 2). Sway, I suppose, doesn't aggregate mouse movements, but looking at https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-... the author used some hack to enable "immediate" "drawing" under KWin. I'm not sure what's the default behavior of e.g. Sway - does it buffer frames?
    - nicce 5y ago
      X.org has many other problems, mostly related to screen tearing or security bugs. It is getting closer for the end of its life as being too complicated and not well designed project. Some list of Wayland compositors: https://wiki.archlinux.org/title/Wayland#Compositors https://wiki.archlinux.org/title/Wayland#Compositors Personal recommendation goes for sway, once you understand it, there is no going back! On Gnome, you must use Mutter I guess.
nicce 5y ago
I have been playing under sway which removes many bottlenecks (or at least haven’t noticed any), you could give it a try https://github.com/swaywm/sway https://github.com/swaywm/sway
- jagrsw 5y ago
  Yup, other compositors might not have this limitation. I might one day switch to sway, but currently staying with Gnome, cause it'd take a couple of days to get used to it I suppose. BTW, gnome-shell supports so called compositor bypass for windows which request it (and games which I play request it via probably libSDL) - more on that here https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm46515148762144 https://specifications.freedesktop.org/wm-spec/wm-spec-lates... - but I still wonder what kind of visual delay I'm getting with gnome-shell vs e.g. sway. My understanding is that with _NET_WM_BYPASS_COMPOSITOR it should be the same (vs non-compositing window manager), but the devil is in the details. I like gnome-flashback/metacity (non-compositing WM), but there are some strange quirks of it, which make me avoid using it on my 21:9 monitor.
1_player 5y ago
The very link you posted says it's fixed in the next version of GNOME.
vbphprubyjsgo 5y ago
Mice have supported 1KHz since the 90s; They are merely set to 125Hz by default. The problem is some can handle low sensitivity and some cannot (due to slow sensor sample rate afaik): http://www.esreality.com/?a=post&id=1265679 http://www.esreality.com/?a=post&id=1265679. This of course is no different than the "gaming" mouse market. Some can handle fast movement, some cannot. 4ms latency is basically nothing (Relatively. Yes, it should be zero). Games already add 10s of ms, modern monitors all add around 3ms-10ms for no reason at a bare minimum. And the latency of each pixel varies depending on the start and end luminance level of a pixel moreso than the [0,8] ms of a mouse at 125Hz being sampled at an arbitrary position in your game cycle (yes, even on many "240Hz" LCDs). Though, it's unclear to me if you get other undesired effects from resampling the output of already sampling the mouse. 1KHz+ mouse sampling's primary benefit is that panning is smooth (perhaps on a properly configured system with a CRT and non-bloated stack then the 8ms max latency becomes an issue). If using a 125Hz mouse polling rate, you circle around an object while keeping your crosshair it, it will be easy to see how wobbly this is. At 1KHz that mostly goes away. Higher mouse DPI on low sens additionally visibly adds to the smoothness.

by jagrsw 5y ago

GhettoComputers 5y ago

Damn, I thought gamers would find it useful. What is wayland even good for?

kevingadd 5y ago
For crashing your games if you move the mouse too fast https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
- GhettoComputers 5y ago
  Thanks, now I know for sure the steam deck will just be another windows computer that came with linux. Even these assumptions about its use case were wrong. How could anyone in good conscious support switching to this? I can see noobs who think newer is better, but wow, horrid. Android is pretty smooth, I wonder if running the framework of it on linux could work lol.
  - 1_player 5y ago
    > now I know for sure the steam deck will just be another windows computer that came with linux Your "This Linux tech is pretty shit isn't it" posturing you've shown all over this thread and other Linux posts is _insufferable_. We don't need novelty accounts to repeat the same trite cynicisms everywhere, there's Reddit for that.
    - GhettoComputers 5y ago
      Feel free to leave the thread because you can’t handle these truthes. Wayland by itself is complete shit and will be enough to ruin the deck experience.
jagrsw 5y ago
Having two monitors with different DPI or physical size. Wayland supports different scaling per monitor, so your windows will look thesameish in terms of physical or pixel size (depending on your wishes) when moving them across monitors :).
- badsectoracula 5y ago
  There isn't really a reason for this to not be done on Xorg too, aside from having the window manager keep track of per-monitor scaling information (note that scaling, physical size and DPI do not have to be tied - someone may want to use a big scale for a low DPI monitor because they have it across the room for example, what really matters is a per-monitor scaling factor - DPI can be used to set up some sane defaults but this should be overridable) and pass it to applications to scale themselves with a fallback if the application doesn't support scaling (be it client-side composition or server-side composition, though the latter will also need merging Keith Packard's patch that implements composition-based server side window scaling)... and someone to specify the messages/events involved. But really almost all the tech exists (aside from server side scaling, but this can be ignored for an initial implementation) and toolkits (or at least Qt and perhaps Gtk) should already support this as Windows scaling works in a similar way, it is largely getting a bunch of different projects to play nice together.
  - jagrsw 5y ago
    I think Qt supports it in some quirky way. It supports this DPI notation of something like QT_DPI="192;128" via envvars. But it only means that when moving window to another monitor the window will get suddenly re-scaled/re-sized, instead of being smoothly drawn using different scaling factor.
    - badsectoracula 5y ago
      Well, yes, this is basically all what applications can do by themselves without support from the rest of the stack. It isn't impossible but it will be limited to application/library-specific hacks and those have a limited view of the system anyway. Ideally you want support from the environment itself and applications only be responsible for scaling themselves properly. The window manager is at the best position to support something like this since it handles window placement. It is possible to have a separate program that can keep track of window placement and support the relevant events too (for window managers that wont support this) but it can be tricky to get it work smoothly. The sudden scale/resize is something that can't really be avoided without support from the compositor (be it the window manager, a separate compositor or server-side composition), assuming there is one of course (this should work without a compositor too, you'd just wont get the scaled fallback unless the server-side scaling patch is also added to Xorg). Again, can be done and the tech is there, it just needs wiring all these things up.
zamadatix 5y ago
Mixed refresh rate monitors.
- pantalaimon 5y ago
  This works on X11
  - zamadatix 5y ago
    If you don't have a syncing compositor which is a bit of a limitation.
nicce 5y ago
This is more about Gnome’s Mutter implementation problem, not directly problem of Wayland. There are other compositors
- badsectoracula 5y ago
  One issue with these "other compositors" is that you aren't just replacing the compositor itself but you have to replace the entire environment.
- GhettoComputers 5y ago
  What compositor should be used? Never heard x.org doesn't have this problem with any.
  - jagrsw 5y ago
    I'm not an expert on the wayland/xorg/xinput/gnome-shell stack, but unless someone smarter takes good measurements of various things (visual and input delays), I'd suggest 1). Xorg + gnome-flashback or Xorg + other non-compositing WM or 2). Non-gnome compositor under wayland As for 1). Xorg b/c it can provide pointer movements at ~native speed via xnput vs Gnome/Wayland 60-240Hz. And gnome-flashback b/c it's a non-compositing WM, so there's no frame buffering (unless you enable it in nvidia's panel, or via TearFree in amdgpu). As for 2). Sway, I suppose, doesn't aggregate mouse movements, but looking at https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-on-wayland.html https://zamundaaa.github.io/wayland/2021/12/14/about-gaming-... the author used some hack to enable "immediate" "drawing" under KWin. I'm not sure what's the default behavior of e.g. Sway - does it buffer frames?
  - nicce 5y ago
    X.org has many other problems, mostly related to screen tearing or security bugs. It is getting closer for the end of its life as being too complicated and not well designed project. Some list of Wayland compositors: https://wiki.archlinux.org/title/Wayland#Compositors https://wiki.archlinux.org/title/Wayland#Compositors Personal recommendation goes for sway, once you understand it, there is no going back! On Gnome, you must use Mutter I guess.

nicce 5y ago

I have been playing under sway which removes many bottlenecks (or at least haven’t noticed any), you could give it a try https://github.com/swaywm/sway https://github.com/swaywm/sway

jagrsw 5y ago
Yup, other compositors might not have this limitation. I might one day switch to sway, but currently staying with Gnome, cause it'd take a couple of days to get used to it I suppose. BTW, gnome-shell supports so called compositor bypass for windows which request it (and games which I play request it via probably libSDL) - more on that here https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm46515148762144 https://specifications.freedesktop.org/wm-spec/wm-spec-lates... - but I still wonder what kind of visual delay I'm getting with gnome-shell vs e.g. sway. My understanding is that with _NET_WM_BYPASS_COMPOSITOR it should be the same (vs non-compositing window manager), but the devil is in the details. I like gnome-flashback/metacity (non-compositing WM), but there are some strange quirks of it, which make me avoid using it on my 21:9 monitor.

1_player 5y ago

The very link you posted says it's fixed in the next version of GNOME.

vbphprubyjsgo 5y ago

Mice have supported 1KHz since the 90s; They are merely set to 125Hz by default. The problem is some can handle low sensitivity and some cannot (due to slow sensor sample rate afaik): http://www.esreality.com/?a=post&id=1265679 http://www.esreality.com/?a=post&id=1265679. This of course is no different than the "gaming" mouse market. Some can handle fast movement, some cannot. 4ms latency is basically nothing (Relatively. Yes, it should be zero). Games already add 10s of ms, modern monitors all add around 3ms-10ms for no reason at a bare minimum. And the latency of each pixel varies depending on the start and end luminance level of a pixel moreso than the [0,8] ms of a mouse at 125Hz being sampled at an arbitrary position in your game cycle (yes, even on many "240Hz" LCDs). Though, it's unclear to me if you get other undesired effects from resampling the output of already sampling the mouse. 1KHz+ mouse sampling's primary benefit is that panning is smooth (perhaps on a properly configured system with a CRT and non-bloated stack then the 8ms max latency becomes an issue). If using a 125Hz mouse polling rate, you circle around an object while keeping your crosshair it, it will be easy to see how wobbly this is. At 1KHz that mostly goes away. Higher mouse DPI on low sens additionally visibly adds to the smoothness.