7 ms·

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.

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.