X.Org Server 21.1 Will Aim To Release In The Coming Weeks

[mppix]

I wonder if asking which wayland compositor should replace X is a better way to stir things up.
And I don't know too much about linux software dev, but for the sake of convenience, could a compositor be written into systemd as some kind of "composed?"

Who are you?
mdedetrich and friends are going to divide themselves in two trying to decide whether they should hate or like this.

Short answer: the compositor with cross-platform adoption is wlroots and you could probably include it in the systemd family.

[mppix]

Not at the time Linus made that video, subsurface only started making Linux releases somewhat recently. But again, you missing (likely deliberately) the whole point being made ergo your uneducated remark about users being idiots because of backwards breaking changes.

(a) I don't know subsurface's history well enough to state when and why they started to make Linux releases.
However, nothing has changed in how distributions operate since LInus made the comments. We have stable distros, rolling release distros and bleeding edge distros. Pick your poison.
(b) I understand you quite well. My statement was that if Ubuntu deprechiates 32bit, there are other distributions still supporting it - and that the wold won't end if someone needs to learn a rpm distribution (or learn that debian still has 32 bit). You are trying to make it about something else (in part with arguments that don't hold water).

Sure I don't disagree with what you are saying here but the critical point here is that optional security is by definition not secure. Yes its possible to sandbox applications via flatpak (like you said, although the degree is debatable) but not all applications are forced to run through flatpak.

This is what I was referring to when I said earlier that for this kind of security to actually work properly, it needs to be non optional. The best way to implement this capability based system in the kernel (i.e. fuschia), or with a system like Android due to the ecosystem design everyone is forced to distribute apps on a single platform (apk's). This also helps enforce that your ecosystem of applications actually takes security seriously, otherwise you get this problem https://www.flatkill.org/2020/

Flatpak allows you to run a fairly tight security model but does not force it to prevent breakage (flatpak allows to blow quite large holes in the sandbox to make things work. This is for example used in the zoom flatpak app (not shipped by zoom) right now to enable desktop sharing.
Sorry, but I need to point out that you managed to reply to two users in the same post arguing for the exact opposite - either you force strict security (and allow breakage) or you dont!

What I don't get is why you (or anyone) would dismiss that under X apps can gain root access fairly easily. All input is available for all apps and all apps can in principle manipulate all apps. Hence, any app can spoof input for passwords or manipulate apps running as root.
In Wayland, apps are isolated and only run as user (not! root) - even if an app manages to get out of the sandbox. Also, sandbox as a concept for GUI apps is largely mood under X.

[oiaohm]

I've never seen a program segfault because X crashes, or just plain quits when it ran through .xinitrc, or whatever. It's always some controlled "crash" with an error message that says the X server disconnected. I don't see why all application memory accesses would suddenly cause a segfault. Perhaps whatever has been allocated by X/driver, but not the memory of the program itself.

This is being old enough. modern day toolkits detect when X11 server is gone and go into a controlled crash. You go back in the early 198. 0s X11 toolkits they were lacking the controlled crash and instead had a reconnect to X11 server yes these would segfault quite common when used with opengl applications. Yes the X/driver had allocated the memory the applicaiton had mapped that memory into it memory space and when the X11 server closed the memory was freed to non allocated without a controlled crash this is segfault. xpra contains quite a few operations where it duplicates the memory between the client application and the X11 server to prevent X11 server termination resulting in client program memory coming not allocated of course they have had a ongoing battle with Nvidia drivers.

What state do you mean? I mean sure, you need to create a new context and perhaps check and synchronize things like window position/size, screen dimensions, keyboard state and so on, but I can't think of anything critical that would be lost. Perhaps back when things were rendered server side using uploaded pixmaps that might get lost and such, but modern toolkits don't draw like that. To an application it shouldn't be any more noticeable than suddenly being resized.

This what you wrote here is how it should really work. Problem we have had is in the shared allocations is Nvidia(Nvidia core X11 driver design comes from DRI1 in this area and why there are still some deprecated DRI1 interfaces in correct X11 server bare metal yes Nvidia is the only party still using them) and in the past DRI 2 (the GEM handle that was removed in DRI3 ) they not been per process instead system global allocation. Now that Nvidia is finally doing GBM and DMA BUF maybe we will be able to move to xpra feature being X11 standard because memory not pulling the magical disappearing act. Please note this global allocation problem happens to local running X11 applications not network running ones.

DRI3 drivers for X11 server are meant to use GBM or a GBM equal. So Nvidia not having a GBM equal has not only been disrupting wayland development but has been making xpra developers time harder than it should have been and limiting the features of bare metal X11 server.

The problem comes performance optimisation here. You don't want to duplicate memory usage so consuming extra ram if you don't have to. But a shared buffer between processes need to remain as long as 1 process is still attempting to use it. Not do what Nvidia drivers and DRI2 GEM have done because in those last process to use the shared buffer if it dies will free it system wide no matter how many applications are using that buffer(the cause of segfaults). . Please note that last process to use the buffer this is not the process that allocated in most cases but the X11 server itself. So we have a nice game of rare here caused by how GPU at different times have allocated memory. Fixing this in xpra results in heavier memory usage than what should be. Fixing it in the driver is the correct way. Once this is fixed in all drivers for X11 the legacy DDX APIs for bare metal for this nightmares can go away.

Eglstreams was attempting to force the old that Nvidia uses with X11 on to Wayland. Yes if Nvidia could have pulled that off they would not need to write as much new code.

[binarybanana]

His issue has been that libraries across distributions have vastly different versions and distributions usually don't allow you to ship your own.

Where does this meme come from? There is nothing that prevents bundling all dependencies with your program. You can even ship your own libc if you really want. Or link statically. The kernel interfaces are quite stable. I can still run Enemy Territory from 2003 on a modern system without issues. (Other than that it uses OSS for audio, but that's technically still supported by the kernel and things like padsp exist).

Expecting things to keep working indefinitely when you ship only half of your program and depend on unstable interfaces is insane. There's no OS where that works. Even on Windows programs come with MSVC++ and DirectX installers included, or just the raw dll in its directory. On OSX shit just breaks every new version and rewriting/compiling is expected and accepted as workable solution.

The only thing you can't do is depend on the distribution's package manager. But if you aren't part of the distribution you have no business depending on any of it. A rouge program isn't part of the distribution and has to ship what it needs if should work independent of the environment, no way around that. The funny thing is proprietary software does it right most of the time, probably because the vendors have experience with shipping binary blobs.

[binarybanana]

Really do not crash the client is the tricky bit that Nvidia has been in the way with. You don't want nvidia eglstreams issue where you restart the GPU for setting up the compositor and now all the memory the client applications have are now segfaults. This why GBM support as long Nvidia does it right will be important because the per process allocation of particular things is required to prevent restarting X11 bare metal or wayland compositor result in crashed applications due to segfault.

I've never seen a program segfault because X crashes, or just plain quits when it ran through .xinitrc, or whatever. It's always some controlled "crash" with an error message that says the X server disconnected. I don't see why all application memory accesses would suddenly cause a segfault. Perhaps whatever has been allocated by X/driver, but not the memory of the program itself.

What state do you mean? I mean sure, you need to create a new context and perhaps check and synchronize things like window position/size, screen dimensions, keyboard state and so on, but I can't think of anything critical that would be lost. Perhaps back when things were rendered server side using uploaded pixmaps that might get lost and such, but modern toolkits don't draw like that. To an application it shouldn't be any more noticeable than suddenly being resized.

GIMP used to support moving its windows across X screens back in the day. While that isn't a sudden crash and not a whole new X server it's similar enough of a situation (can be different pixel formats and whatnot) to show that it should be doable.

[doomie]

I wonder if asking which wayland compositor should replace X is a better way to stir things up.


And I don't know too much about linux software dev, but for the sake of convenience, could a compositor be written into systemd as some kind of "composed?"

[arQon]

Great work Povilas for the effort to get the community a new X release.

As for the flame wars between X and Wayland, my stance is simple - X works for all my use cases. Wayland kind of works.

Will stick with X till Wayland dots it's I's and crosses her t's.

That's the "sensible" position, certainly.

I'd be perfectly happy to just ignore Wayland entirely until the day it's actually ready, but every couple of months Michael chums the water with yet another article about how the only actually-working *nix desktop is "irrelevant", or Wayland "advances to v0.581, now just a few months away from being usable, honest" for the 50th time, and then a swarm of newbies who've never written a line of code in their life suddenly become "experts" who parrot-spam the claims of how X is causing the world to end. Year after year after year.

The problems only really start when the 0.1% of rabid Wayland fanboys manage to talk distros into shipping Wayland by default: but once that happens, "normal" users end up with broken systems for reasons they don't understand and have no way of fixing. It sucks for users in general, but it especially sucks if/when you're the one handling "tech support" for family and friends.

[arQon]

Right, screw this. I've had enough.

At this rate desktop Linux will never ever fully transition to Wayland and developers will simply continue to flog the zombie that is Xorg and the Xserver. Things like VR, HUDs and even newer exciting stuff will simply get grafted onto Xorg like the shitbag that it is. Let's continue to deal with having a kernel driver, a drm driver and an Xorg ddx driver just to draw the desktop instead of having everything done by the drm driver. And while we're at it, let's also continue to enjoy the clusterfuck of device-specific input drivers compared to have everything punted off to a general Wayland protocol extension.

Sounds fine to me. A "general Wayland protocol extension" for input just means "device-specific extensions" rather than "device-specific drivers", and while I haven't wasted much time keeping up with the moving-target, excuse-riddled hackfest that is Wayland, those two options don't sound too different to me. (And if anything, I'd rather some random RTS-style 20-button mouse DID have its own driver, to quietly die when no longer needed, rather than have that code be part of a 4000-case switch statement in every machine for eternity).

> Everyone might as well simply roll back all the efforts to create Wayland compositors and software that actually function properly on Wayland

Well, if those things existed in an actually-functional form in the first place, *we wouldn't be having this discussion*.

> even after 13 years of Wayland development.

Yeah, well, if "after 13 years of development" all you have is a pile of crap that STILL isn't ready for primetime, your project is pretty clearly an utter failure.
Just imagine if all that wasted energy had gone into refactoring and working the X server instead, as it should have: most of X's problems would have been resolved by now. (Except they wouldn't: not because it's not possible, but because we've seen that the Wayland devs are so caught up in a mixture of being out of their depth and living in some fantasy land that they can't actually deliver working code).

> If things ... don't work properly on Wayland, don't bother with wasting effort to address them because

Because, IDK, maybe after 13 years of failing to manage that, when all these pieces were already well-known before the project even started, one should maybe accept that the inability to deliver them is not just a failure in the basic design, but also a failure to learn anything for over a decade, and a failure to even attempt to put the needs of the project above the vanity of the developers.

You've "had enough" because you're emotionally invested in a project that has been nothing but hype and vaporware for 13 years. Maybe it's time for you to move on. It's certainly LONG since past time for the Wayland team to - but as long as they're getting paid to do nothing except write blog posts every few months about how great Wayland is and/or how shitty X is and how they're SO much smarter than the original X devs, why would they?

FFS, learn some history. Take a look at how long X took to write. Take a look at how long XFree took to create. Look at how long each protocol revision took, the extensions, the moves to DRIx, etc - even the most massive, impactful changes to X over the years went from start to finish in literally a tenth of the time that Wayland has taken, with a smaller team, doing original work rather than just re-implementing solved problems.

There isn't really that much wrong with Wayland as a concept, sure - but Wayland as a *reality* is a very different story. It's an utter farce, and - regardless of how much you, Michael, or anyone else tries to pretend otherwise - it will always remain nothing more than that until the Wayland devs fix the design, fix the code, and actually deliver on their promises: something that history has shown is highly unlikely to ever happen.

[Snaipersky]

As promised, not sure where I should post this for gitlab, but my log of merging non-xwayland patches from back in March.

xserver merge log - some had to be reverted or required intervention, mentioned at end

MR !24
MR !36
MR !119
MR !124
MR !139
MR !158
MR !174
Not thrilled with that, should've made a checkpoint just before. Lots of small, seemingly innocuous changes, but I still don't fully get everything they're trying to accomplish
God it's trippy seeing "Copyright 1987, 1998 The Open Group"
MR !181
MR !187
MR !191
MR !198
MR !209, ftrace is a thing now, hopefully.
I think I'll leave !211 alone for now.
There's potenial for big gains, but might harm nvidia users.
!220 requires external changes, I'll leave it alone.
MR !229
MR !231 invalid, all changes already merged.
MR !233
MR !273
Leaving !276 alone
MR !284
Leaving !306 alone
MR !310
MR !315
MR !320
MR !328. God I love single file merges.
MR !337 / MR !607 - they're effectively the same.
MR !401
MR !404, fourcc.h was missing entirely, moderately concerning.
MR !426
MR !430
MR !440
MR !445
MR !453
40 MRs left to sift through.
My whiskey supply is looking sad.
MR !461
MR !469
MR !481 Amlogic ARM boards with OOTB X support now? also had to bump odev_attributes_version, and don't know if I understand the full implications of that. Hopefully no driver recompiling.
MR !528
Man, a lot of these are getting nasty.
Some fixes being blocked by intel not wanting to fix a fault in their driver for not correctly handling modifier requests, and lots of wayland dogmatic responses. "is it good? it's not for Wayland or xwayland, so it's irrelevant, no one cares" ~90 okayed MR's beg to differ.
Another concern raised by Valve about wanting emulated input - "not a large enough demand" ***** there's about 2 million linux steam users. Where the **** do you draw the line for "enough"?
MR !559
MR !568
MR !575
I want to merge !585, but I just don't know enough to follow if it's actually doing anything, and if it is, is it helpful or harmful.
MR !589
MR !592
Hah, not touching !600.
MR !611
MR !612
MR !634

had to revert 5 MRs, !24, !187, !273, !315, and !404
MR !24 /hw/xfree86/drivers/modesetting -> revert
MR !158 /present/present_vblank.c -> revert / line155, target_msc is not a pointer? (no *)
MR !187 /dix/colormap.c -> revert
MR !273 /mi/mscrinit.c -> revert
MR !315 /hw/vfb/InitOutput.c -> revert
MR !404 glamor/glamor_picture.c -> revert
/hw/xfree86/common/xf86Helper.c -> change 'ddc' to 'probed' ( else if (probedWidthmm && probedHeightmm) {)
/hw/xfree86/modes/x86RandR12.c -> missing closing brace at end of 809-813
/glamor/glamor_copy.c -> missing }; at end of 154-166
/glamor/glamor_xv.c -> needs path expansion at line 44 ( #include "../hw/xfree86/common/fourcc.h")

[ssokolow]

This also helps enforce that your ecosystem of applications actually takes security seriously, otherwise you get this problem https://www.flatkill.org/2020/

Ahh, the famous FUD site that:

• Tries to claim that GNOME UX idiocy is proof that Flatpak itself is fatally flawed.
• Uses statements that have been tested and proven false in reply posts, like "Almost all popular apps on Flathub"
• Uses bombastic prose, makes no effort to steer readers in a productive direction, and just trashes on Flatpak.
• Has no byline or other indication of who's responsible for writing it or how to contact them with corrections and seems to have left the registrant information empty in the domain's WHOIS. (If OVH offers an internal "fill our ReCAPTCHA to get the full record" system with more info, I can't find it.)

To be honest, it's only a little bit of colour and font size variation away from being Time Cube... and at least Time Cube's author was honest enough to tell you who he was. (Hell, at least Time Cube had enough character for people to make parody sites like Slime Cube and Game Cube.)