X.Org Server 21.1 Development Snapshot Released

[tchiwam]

Funny how I remember running X with shared nfs /home on various terminals and being able to do decent work remotely too.

Now even the worst remote share whole desktop is faster and easier to interact with. Anyone tried running firefox or chrome X remote over ssh lately ... Yikes ...

[mdedetrich]

(This is with a cheap Sony TV, which probably isn't setting any world records either latency wise)

Depends on the panel you have, not on the cost of the TV (i.e. if its an IPS panel you will always get fast response times and hence low latency unless the TV is doing post processing which you can usually turn off).

[MrCooper]

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.

Doubtful. Fullscreen unredirection is working fine in mutter, at least with X11 clients via Xwayland. I suspect what they might have referred to is that Mesa's EGL code for native Wayland apps currently doesn't make sure buffers are scanout capable, so fullscreen unredirection can generally not be used for those yet. Mesa is waiting for the dmabuf-hints Wayland protocol extension for this.

If the games you tested use mouse input, the issue addressed by mutter MR 1915 is likely a big factor for the latency you saw. If they use OpenGL (as opposed to Vulkan), that could be another factor (in which case mutter merge request 1880 should help).

For a specific example: I'm playing racing games (using Vulkan via DXVK) on mutter (with MR 1762 applied) via Xwayland, and I'm not seeing any significant latency between my steering wheel movements and the corresponding movements of the virtual steering wheel in the game. (This is with a cheap Sony TV, which probably isn't setting any world records either latency wise)

[oiaohm]

Again irrelevant, redhat/canonical's hand will be forced on way or another (if they care about their users)

Redhat hand is forced as Redhat paying enterprise users don't want the security problems of bare metal X11. This is why Redhat is funding the maintainer of the XWayland bit.

I am talking about basic features that are expected of desktops which work reliably out of the box. Wayland is quite far from achieving this goal for everyone.

There is another problem the basic feature of in fact being secure that enterprise customers expect bare metal X11 server is no were near close either. So this comes down to what basic features you class as critical. Redhat is going a particular direction because that is what their paying user base wants.

Now if parties don't want the Redhat path someone in those parties has to fund developers.

mdedetrich the problem here is not everyone idea of the basic features that are expected of desktops is the same. This is a hard reality. Lot of Redhat customers put security above a lot of the functionality. Like you think you have a Linux desktop commanding predator drone this makes security quite a bit more of a requirement than being the most friendly to use desktop. Of course they still want a desktop interface for doing different things.

Reality of Wayland is a lot of features have had to go back to the design board due to being done insecure under X11 and being insecure not going to be tolerable going forwards to the paying customers of Redhat and Suse and Canonical(ubuntu). This is the problem a lot of what you call basic features to the parties that a paying contracts to Redhat and Suse and Canonical are classed as optional feature compared to security that is a mandatory feature to be achieved.

[mdedetrich]

It's not. Companies like redhat, canonical and all those won't be able to sell support contracts for things containing xorg in some not to distant future, so all financial backing of old x11 will fade away.

Again irrelevant, redhat/canonical's hand will be forced on way or another (if they care about their users)

And thats a good thing, we shouldn't change that massively. One of the primary reasons why the Wayland ecosystem is better: there is so much old cruft in xorg, that we should get rid of that, removing the need for maintenance, improving user security, trashing things unused in years or decades. Usecases shifted, your mind maybe didn't.

I am talking about basic features that are expected of desktops which work reliably out of the box. Wayland is quite far from achieving this goal for everyone.

[Hibbelharry]

Whether or not an "official" release is made is kinda irrelevant.

It's not. Companies like redhat, canonical and all those won't be able to sell support contracts for things containing xorg in some not to distant future, so all financial backing of old x11 will fade away.

Wayland hasn't replaced all of the use cases of X.Org

And thats a good thing, we shouldn't change that massively. One of the primary reasons why the Wayland ecosystem is better: there is so much old cruft in xorg, that we should get rid of that, removing the need for maintenance, improving user security, trashing things unused in years or decades. Usecases shifted, your mind maybe didn't.

[oiaohm]

I'm pretty sure that distros will have switched to either Wayland or Arcan in the next few years, so 21.1 would be the last X.org version ever, meaning that ABI stability is permanently guaranteed from here on out.

No ABI stability of the X11 is not permanently guaranteed with 21.1 . Problem here is XWayland and Xquartz based off 21 are free in future to do a ABI breaking 22 or even in 21 time frame if ANSIC, XINPUT or EXTENSION ABI bits require a breaking change. 21 may be the last with VIDEODRV ABI. Arcan for X11 support is XWayland to be it Wayland or Arcan the support for X11 clients is done the same way.

Really when X.org X11 22 comes around I would not be surprised if this is not Xwayland and Xquartz with zero bare metal support. Yes no maintainer for X11 21 and no 21 formal release used as the reason to removal bare metal support in 22 .

I really do see x.org X11 on bare metal in current state being a dead end.

[oiaohm]

Wayland hasn't replaced all of the use cases of X.Org (and its current rate this will take years to fix itself), the current unreleased version of X.Org has (ironically) many features that are needed/useful for a migration from X.ORg -> Wayland and hence a lot of distro's will just end up using this "unreleased" version of X.Org, because, well, they are forced to.

This is right and wrong.
XWayland and Xquartz what is are subset of the X11 x.org server has been doing formal releases this is a cut down feature set release of x.org. This kind does make things simpler as both of these are we don't have "VIDEODRV" Abi so we do not need to worry about that.
Yes ANSIC, VIDEODRV, XINPUT and EXTENSION are the 4 X11 abi. Xquartz and Xwayland both don't need VIDEODRV ABI and the only X11 ABI to really change since 20 with 21 is the VIDEODRV ABI including some very major changes to VIDEODRV ABI to support upscaling on 4K monitors proposed by Nvidia between 20-21.

The reality here ix both Xwayland and Xquartz released are avoiding the hardest bit the bare metal support.

[CommunityMember]

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.

And you did not even mention what can be the hardest part, the herding of cats (developers and users) to properly report, validate, fix and confirm the fix again and again any issues identified during the QA time of a new release. As X runs on so many highly disparate platforms (and no org has one of every combination of them), anyone who takes on a release manager role has to depend on many others to do the actual work, and while some are highly motivated and responsive, some require constant engagement ("is it fixed yet? is it fixed yet?") to get things ready for a real release.

[MadeUpName]

*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.

The Open Indiana guys I can see wanting a desktop. But I wonder if BSD could implement some thing far simpler than X for the install and then just do any thing they might want graphics for with a web server. It's not like any one runs BSD for the leading edge graphics experience.