X.Org Server 21.1 Development Snapshot Released

[user1]

Wayland devs better hurry up and implement the protocol that allows to disable vsync for fullscreen windows. Otherwise, gaming just sucks on Wayland (from my own experience on Gnome Wayland session). I mean it's nice that XWayland now achieves comparable performance to bare metal X, but what's the point of it when the forced vsync causes an awful input lag, even when vsync is disabled in the game itself?

[uid313]

*BSDs have barely enough people to maintain *BSDs. Illumos, OpenIndiana, Augustiner Schweinshaxe and OpenIndiana are maintained and used by like 3 people, and I doubt anyone of them does want to bother with Xorg.

Wow, that's incredible that an operating system is maintained by just three people.

I guess nobody is going to step up to maintain X.Org then, so then I guess all distributions and operating systems that use X.Org will stay with an old version, unless they port Wayland to their OS.

[bobbie424242]

A release means it has to be maintained for years to come. No one wants to do that.

Maintained how ? It's not like Xorg is unstable or heavily evolving software that requires constant attention.
I still do not understand it what prevents Xorg to make an official release with the improvements from the
last 3 years, instead of sitting on it potentially forever, making that effort wasted...

[acobar]

Maintained how ? It's not like Xorg is unstable or heavily evolving software that requires constant attention.
I still do not understand it what prevents Xorg to make an official release with the improvements from the
last 3 years, instead of sitting on it potentially forever, making that effort wasted...

What is holding it back is not the bull*it of "years to come". There are many steps and tests needed to have a stable release for important projects and all guys involved on graphics stack FOSS just want Wayland to be adopted ASAP, even if it still has many flaws (as so has X, regardless of been very, very stable for me on last 10 years or so, but security wise, it is a mess).

[oiaohm]

Maintained how ? It's not like Xorg is unstable or heavily evolving software that requires constant attention.
I still do not understand it what prevents Xorg to make an official release with the improvements from the
last 3 years, instead of sitting on it potentially forever, making that effort wasted...

Oboy you have really taken a horrible wild guess here.

https://www.x.org/wiki/XorgModuleABIVersions/

ABI of a x.org X11 server when comes time for release has to be formally documented and validated. Then when the release is done you have to maintain that ABI stability for quite a few years. If you have not worked out as part of formally doing a X.org release is working out what is now deprecated and now will be removed. The development snapshot stage is before you start threatening to remove features Nvidia or other may depend on. This removal is also about reducing the code based that has to be maintained into the future.

Take a close look at those ABI versions every time those version numbers increase something about the ABI of the x.org X11 server has changed. Do take a close note at VIDEODRV between version 1.19 and 1.20 yes it goes from 20 to 23 in the release process from 1.19 to 1.20 the VIDEODRV ABI changed 3 times. Doing a X.org X11 release can quickly turn into a email flame fest of different parties arguing for and against different api feature removals yes and who ever chooses to be the maintainer x.org X11 for the next cycle gets to be the arbitrator between these as part of taking the job.

Yes maintainer is not going to require constant attention for the complete release time. But agreeing to be the maintainer means you have agreed to take on possible 6 months of being email bombed with issues to sort out on what features should and should not make it into the release you are going to take care of. Yes you are agreeing to take maintainers job for the next stable is also agreeing in X11 x.org development to take charge in the time frame that ABI stablity going out the window this is not a fun job.

[Alexmitter]

Maintained how ? It's not like Xorg is unstable or heavily evolving software that requires constant attention.
I still do not understand it what prevents Xorg to make an official release with the improvements from the
last 3 years, instead of sitting on it potentially forever, making that effort wasted...

Most of that effort is Xwayland effort, that is why Xwayland is a standalone package now.

[bobbie424242]

Oboy you have really taken a horrible wild guess here.

https://www.x.org/wiki/XorgModuleABIVersions/

ABI of a x.org X11 server when comes time for release has to be formally documented and validated. Then when the release is done you have to maintain that ABI stability for quite a few years. If you have not worked out as part of formally doing a X.org release is working out what is now deprecated and now will be removed. The development snapshot stage is before you start threatening to remove features Nvidia or other may depend on. This removal is also about reducing the code based that has to be maintained into the future.

Take a close look at those ABI versions every time those version numbers increase something about the ABI of the x.org X11 server has changed. Do take a close note at VIDEODRV between version 1.19 and 1.20 yes it goes from 20 to 23 in the release process from 1.19 to 1.20 the VIDEODRV ABI changed 3 times. Doing a X.org X11 release can quickly turn into a email flame fest of different parties arguing for and against different api feature removals yes and who ever chooses to be the maintainer x.org X11 for the next cycle gets to be the arbitrator between these as part of taking the job.

Yes maintainer is not going to require constant attention for the complete release time. But agreeing to be the maintainer means you have agreed to take on possible 6 months of being email bombed with issues to sort out on what features should and should not make it into the release you are going to take care of. Yes you are agreeing to take maintainers job for the next stable is also agreeing in X11 x.org development to take charge in the time frame that ABI stablity going out the window this is not a fun job.

Thanks for this detailed explanations. It tells much how the release process of Xorg is overly complicated and cumbersome, to the point nobody wants to sacrifice himself to commit to it. It's a miracle most other software release process is not like that and software gets released all the time.

[oiaohm]

Thanks for this detailed explanations. It tells much how the release process of Xorg is overly complicated and cumbersome, to the point nobody wants to sacrifice himself to commit to it. It's a miracle most other software release process is not like that and software gets released all the time.

This level of cumbersome is why at times stable API/ABI suggestions for drivers with the Linux kernel has the hell no response at times. ABI stability does bring it own fair share of nightmares. Majority of projects don't have stable API/ABI requirement. The difference is not a miracle just most people cannot dream what the cost of maintaining and documentation of a stable ABI really equals and why having stable API/ABI is not quite as hot of a idea as it first appears..

[MrCooper]

Wayland devs better hurry up and implement the protocol that allows to disable vsync for fullscreen windows. Otherwise, gaming just sucks on Wayland (from my own experience on Gnome Wayland session). I mean it's nice that XWayland now achieves comparable performance to bare metal X, but what's the point of it when the forced vsync causes an awful input lag, even when vsync is disabled in the game itself?

Tearing isn't required for good latency.

A big factor for input latency is that mutter currently sends mouse input events to Wayland clients only once per display refresh cycle, which mutter merge request 1915 addresses.

mutter merge request 1762 also reduces the minimum output latency incurred by mutter.

[user1]

Tearing isn't required for good latency.

A big factor for input latency is that mutter currently sends mouse input events to Wayland clients only once per display refresh cycle, which mutter merge request 1915 addresses.

mutter merge request 1762 also reduces the minimum output latency incurred by mutter.

Well, idk about these, but I remember discussing the topic in other forum and when I said that Gnome 3.38 supposedly has fullscreen unredirection, a dev who contributed to kwin wayland code replied to me that fullscreen unredirection is broken on Wayland and this itself will require a new Wayland protocol to fix. So maybe that also explains why I had terrible input latency.