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

[Myownfriend]

eglstreams was designed to be so called OS netural so its missing the file descriptor requirement because this would mean platform dependant code. Of course DMA BUF and GBM are both designed to use host file descriptors.

Oh right! I remember hearing this when I was trying to look up the difference between EGLStreams and GBM.

I was only specifying that Wayland doesn't require GBM because I so often hear about people talking about them as if GBM is a part of Wayland or something.

[Myownfriend]

On both my laptop and desktop, I try and fail to switch over to Wayland every few months. It's not that I don't want to, I literally could not use Wayland to do my work. For example, during the first wave of COVID the video teleconferencing software packages were all broken under Wayland, but worked perfectly under X11. In your utopian Wayland-only world, what was I do to?

Was one of them Microsoft Teams by any chance?

Did you ever think that your perfect Wayland protocol

Why do you people talk like this? It's such flat-earther energy.

Did you ever think that your perfect Wayland protocol, requiring this massive undertaking of every Linux desktop writing their own Wayland compositors, has led to this 13 year wait? The 2 most popular desktops KDE and GNOME both have their share of bugs with Wayland for the most basic desktop features like copy/paste and screen sharing.

I don't know where people get this idea that software gets to a point where their are no bugs. For every-updating software like DEs, there are always bugs. That doesn't reflect them being unstable or not ready for use. X11 still has bugs and it's been 34 years since it hit version 11.

About screen sharing, for the millionth time in this thread, X11 allows any application to view the input and frame buffers of every other application. It's a security flaw that gets used for screen sharing. Wayland does not allow applications to do that and thus requires Pipewire support to do that. Screen sharing is neither a feature of X11 nor a flaw of Wayland.

After 13 years, you ever think it's Wayland itself, not keeping X11 on life-support, that's the primary cause of these problems?

Sure, Wayland was still being worked on for a while but that's not it's primary cause of problems. The Nvidia EGLStreams thing has been going on for nearly half that time.

[tomas]

.... their own Wayland compositors, has led to this 13 year wait?...
After 13 years,....

Can we please, please agree on sticking to reality, ok?

Wayland, as in the protocol, as in the specification, as in a text document, is 13 years old. Gnome's compositor Mutter has implemented the Wayland protocol since Gnome 3.20 released in March 2016, five and a half years ago. KDE started the migration to Wayland much later than this.
So we are not talking about 13, 12 or even 10 years. We are talking 5 years for Gnome and just a few years for KDE.

Thank you for listening.
You may now continue the discussion.

https://en.wikipedia.org/wiki/Waylan...rver_protocol)

[Weasel]

The simple fact that any X application can read the contents (including keyboard input) of any other X application in the same session is enough. There is really nothing more discuss, it's simply a broken design from a security perspective.

That's required for things like AutoHotkey to function. BTW, on Windows. Looks like X is perfectly sane to me.

[Weasel]

About screen sharing, for the millionth time in this thread, X11 allows any application to view the input and frame buffers of every other application. It's a security flaw that gets used for screen sharing.

Windows allows it and is infinitely more significant than your pathetic mobile toys and Wayland.

Just because YOU don't find a use for them doesn't mean they are security flaws.

Here's a quickie. Use AutoHotkey to make a macro that depends on the screen contents of another application (for example, to automate something in a CAD or a game, even when off-screen or minimized). Perfectly possible under both X11 and Windows. Not possible with toys like Wayland.

[oiaohm]

Oh right! I remember hearing this when I was trying to look up the difference between EGLStreams and GBM.

I was only specifying that Wayland doesn't require GBM because I so often hear about people talking about them as if GBM is a part of Wayland or something.

I get it. Those people also missed that its the host file descriptors/handle that is the real problem.

https://lwn.net/Articles/517375/ sorry I got the year wrong it was not 2010 it was 2012. This change from using GEM Buffer or some other GPU vendor buffer solution to host file descriptors/handle is to allow working with the Linux/BSD OS host security. Yes this bring mandatory need for DMA BUF support and GBM features also need to use file handles. So Nvidia has been stubborn for over 9 years on this point at least they are finally coming into line.

This is quite a major security fix so that an application cannot snoop on a output of another application without permission. Like you don't want password dialogs where people is entering password in plaintext to be snoopable.

Trying to make Linux security modules work with X11 server has been a pure nightmare. http://selinuxproject.org/page/NB_XWIN Yes has result in needing X11 server per application.

Wayland you can get away less. Yes just because wayland compositor has a file handle from application to display something on screen does not mean the wayland compositor by the Linux security module has the right to read the contents of that buffer this is a feature that comes from using host file descriptors/handle.

This is something that is required to fix a security fault in the historic X11 server design. This also mean companies like redhat/ibm, suse... making enterprise distributions want to know how the gpu is in fact managing the memory to make sure that stuff that selinux or equal says is high secure does not end up in insecure storage.

People who say there has not been security problems have not looked at why selinux and other parties have jumped though insane number of hoops attempting to secure X11. Reality it should not be anywhere near that hard. The cause is that X11 was another thing design to be host neutral so not integrate with the host OS security.

Yes not being integrated with the host OS security makes implementing security a cluster of horrible hacks that are insanely hard to review if they have achieved the security target.

Please note that nvidia pushing the per vendor buffer solution that is not secure for the past 8-9 years has also stalled work on how to restart the compositor. Think about it with eglstreams since you are using nvidia only private buffer solution this results in the compositor restarts and all the application buffers go away.

Another feature of the file descriptor/file handle on linux. Fun open open a file in a text editor or equal then delete the file off the disc then check the /proc for your text editor you will find that the host file descriptor and the file on disc still exist as long as the text editor kept the file open and has not closed it yet. This is a key requirement to be able to restart a wayland compositor. Heck if we can move to using host file descriptors inside X11 as well in theory it should come possible to restart the X11 server while leaving the windows manager and applications up.

People talk about means to restart the X11 windows manager as wanted feature. People don't think about the elephant in the room why can they not restart the X11 server itself. Part of getting to being able to restart wayland compositors and the x.org X11 server itself without stopping/restarting applications is this change.

Then people talk about restarting graphics drivers. Yes if graphics driver has gone stupid reality here you need to restart the wayland compositor/X11 server as well without killing the applications. MS Windows the compositor can restart due to using windows objects for buffers without restarting applications. Yes Microsoft windows got the means to restart the compositor before any GPU vendors drivers for windows had the means to be restarted. There is a order of operations here.

GPU vendor buffer solution instead of a generic solution has been functionally crippling the Linux desktop. Yes this include GEM buffers and other things like from the open source drivers as well as the Nvidia crud. So GBM or equal support and DMA BUF really are not optional features.

Windows it objects is your generic for buffers. Unix/Posix/BSD/LInux/Mac OS/IOS... you generic host file descriptors/handle for buffers. Its taken us far too long to start fixing this correctly. Yes X11 not being part of the Posix standard has not helped. X11 server internal buffer management is total case of reinvent the wheel 30+ years ago leading to on going security nightmares. Yes it took until 2012 to wake up that this was really the case. Then it taken to 2020 to get Nvidia to wake up that this is also the case. Just because something is decades old does not mean it does not have a fundamental mistake.

[Mez']

Just wanted to be very productive and say "in your face" to the simpletons repeating ad nauseam and without even understanding what they're talking about that "Xorg is dead already". It's always great when bigots are proven wrong.

[oiaohm]

That's required for things like AutoHotkey to function. BTW, on Windows. Looks like X is perfectly sane to me.

I would not be too sure.

Here's a quickie. Use AutoHotkey to make a macro that depends on the screen contents of another application (for example, to automate something in a CAD or a game, even when off-screen or minimized). Perfectly possible under both X11 and Windows. Not possible with toys like Wayland.

This is not 100 percent true. A few things are wrong. AT-SPI2 supporting applications under Linux with the program off-screen or minimised can be controlled by AT-SPI2 even under Wayland. There are even cases under X11 where AT-SPI2 can control the off-screen application but autohotkey cannot. Attempting to control a windows that is off screen not getting any CPU time because it off screen results in nothing happening. AT-SPI2 that off screen application gets put back on the CPU que to get CPU time.

Yes off screen window not getting CPU time can happen under windows as well. So if application support assist technology you should use it. Please note this is a bug with autohotkey under windows as well. Windows does have their own AT-SPI2 equal and if used for a off screen window not getting CPU time will result in that window being put back on the cpu que. There is a right way and a wrong way to interface with off screen windows if you want 100 percent reliability and that not how autohotkey does it. So yes saying that autohotkey works with off screen windows means you must not beaware of that bug when the off screen window is suspended so autohotkeys actions are not waking it up.

https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon/

Interesting enough there is another program called dogtail that needs the same features as AutoHotkey. ponytail here got dogtail working with Wayland.

Please note this other route it possible that you attempt to send a key/mouse action to a particular window by ponytail and you get told no way in hell you are not running with enough privilege todo that.

There is more than 1 way to solve this problem. Question do we really need to solve the autohotkey problem without permission control. Remember the ponytail example here says you can do all the same functionality as autohotkey but with permission control on what applications you can in fact do it to under Wayland.

[Charlie68]

So a "trivial" Xorg update triggers this whole mess? Worrying!
I've read exaggerations from those who are outraged by this Xorg update and the usual Wayland jokes.
I want to remind you all, that to date the only DE that uses wayland by default is Gnome.
KDE is starting to get good support, I use it myself on a daily basis, but it is still under strong development.
Xfce does not have a wayland session yet, Mate does not have a wayland session yet, I will not go further in the list as it is long.
It is not a question of will, it is a question of means ... for how wayland was created, the small DEs are struggling to switch to wayland, because it takes a lot of work.
Kde has contributed to the creation of APIs that didn't exist (they existed to work only in Gnome) and that will help even minor DEs to move to wayland, but it takes time.
So what's the deal if Xorg gets an update? What should the Xfce user who has no wayland support do? A Xorg, there is no alternative.
If they wanted a quick switch to Wayland, they would have to create something other than a protocol and that's it.

[oiaohm]

Just wanted to be very productive and say "in your face" to the simpletons repeating ad nauseam and without even understanding what they're talking about that "Xorg is dead already". It's always great when bigots are proven wrong.

Please note at the time when I was start saying core Xorg was dead there was no maintainer to take the branch forwards. The current proposal for the next xorg release has not been confirmed to have long term employer support.

This is not being bigot. Open source project do from time to time return from the dead. But when development is dead playing along that its alive is wrong. You would say that x.org X11 server development is currently getting a attempted CPR to bring it back from the dead. But its core heart of X11 development has not got confirmed as in fact back beating correctly. Remember the IBM/Redhat and Suse developers are no longer working outside Xwayland. This is a large team gone. The missing developers here still have to be replaced as part of the revival process.

Bring a project back from dead back to healthy development has a horrible 1 in 100 success rate. Its not impossible but its not easy. If you need X11 bare metal and you can afford to provide some developer time I would recommend you do. If no one does this we can fairly much suspect that 21.1 will be just a ill-fated attempt.

Mez I don't mind in those things being proven wrong. But I am not proven wrong with dead projects when people go someone else can fix that result in Mr Nobody being left with a insane work load that is progressing no where result in the revival of the project failing. Time will tell if people are willing to invest the resources need.