X.Org Could Use More Help Improving & Addressing Its Security

[mppix]

XQuartz is also based on X.org, it shares the majority of code, XQuartz "only" handles the integration with MacOS and graphical rendering, window manager.
Just read the first sentence on this page, if you wish to argue about the systems, which you are not familiar with.

https://www.xquartz.org/

XWayland is also based on X.org

Nowadays there is very little code duplication in various X11 implementations.
By code duplication I mean independent re-implementation of the same protocol. The opposite of code sharing, which we have now.

Correct. Do you like monopoles?

[oiaohm]

For the past 15 years or so the X.org server has been used by absolute most of people who needed to run X11 applications.

http://www.microwindows.org/

15 years ago you still had HPUX and other still shipping xfree86. You also had items like mirowindows for light memory systems.

Also 15 years ago there was 5 core engines in X.org server itself. The two biggest was kdrive new design and the legacy deisgned heavily around what came from xfree86. Yes some distributions before 2010 were building with the kdrive stuff others with the xfree86 stuff so you were using .X.org but you were really using 2 different X11 servers yes this also caused some fun problems and this was one of the causes why you would have two distributions with the same X.org X11 server version yet application would only interface with one but not the other this would still happen up until about 2012-2016. Yes Xvfb replacing old xfree86 parts in X.org server is 2016.

birdie over the past 15 years a lot of different projects in fact merged into x.org X11 server. Yes the last 15 years 8 different X11 servers were absorbed into x.org X11 server. Yes this is why x.org X11 server does need a major prune and that has been happening with the 1.20 release process. Yes the fun part knowing you had X.org server that was version X was not enough to answer if something would or would not work.

How did X11 server at x.org get to be the dominate one the answer is horrible by absorbing fragments of the X11 servers it was competing with. Also birdie you were incorrectly thinking 15 years ago X11 X.org server was in fact just 1 server. Fragmentation is not a new problem. X.org X11 server fragmentation managed to do it under one name with one version number this has to be the absolute worst way todo fragmentation.

[sinepgib]

So the sole survivor who may still do vector drawing call in mainstream use is Windows RDP? Or have they also switched to transmitting only pixmap too?

No idea, but I guess it depends on whether the applications produce their own images or not. Non-native stuff like Electron-based apps don't have a lot to send in that way because they don't use a windowing system to draw their widgets.
X.org still allows sending drawing calls (it's part of the X11 protocol), but AFAIK the popular toolkits (and thus applications written with them) use a canvas and call it a day. FLTK apps probably still use such calls tho.

[kreijack]

[..]
I think we can safely turn it around: non-sensible folks are trying to insist on Xorg - with limited to no rationale

I think that this doesn't reflect the reality. A lot of people use Xorg, because wayland.. doesn't give any advantage to justify the switch; more in some case it doesn't support (and likely will never support) modes of working that the people are used to.

I think that an error of the Wayland developers did was to not provide an "equivalent" of X11. From one side they choice to implement a subset of the X11 functionality (the drawing), without supporting input and all other protocol which implement the application interchange of information (like d&d, even if now the things are better). On the other side they coalesced the graphic server with the window manager.

For example I am used to the "focus follow mode" and "raise on click on the title bar". I am comfortable with these because I can put the windows on the screen where and how I want even overlapping and working of all these.

This way of working is implemented in the window manager which must have control of the title bar of all windows. Wayland, implemented as CSD, prevent that. Even in X11 the a CSD application (like gnome-calculator) doesn't work well...

[kreijack]

So the sole survivor who may still do vector drawing call in mainstream use is Windows RDP? Or have they also switched to transmitting only pixmap too?

I think that the Windows GDI (and RDP) and X11, had the same fate. They started as vector graphics system capable to work even in bitmaps. Now every application manipulate only bitmaps. The special effect (not only eye candy, think about the anti-aliasing around a font) are implemented passing bitmap back and forth.

RDP / X11 likely work only with bitmap; in fact we could say that VNC was a "precursor" :-)

[mdedetrich]

I think that this doesn't reflect the reality. A lot of people use Xorg, because wayland.. doesn't give any advantage to justify the switch; more in some case it doesn't support (and likely will never support) modes of working that the people are used to.

I think that an error of the Wayland developers did was to not provide an "equivalent" of X11. From one side they choice to implement a subset of the X11 functionality (the drawing), without supporting input and all other protocol which implement the application interchange of information (like d&d, even if now the things are better). On the other side they coalesced the graphic server with the window manager.

For example I am used to the "focus follow mode" and "raise on click on the title bar". I am comfortable with these because I can put the windows on the screen where and how I want even overlapping and working of all these.

This way of working is implemented in the window manager which must have control of the title bar of all windows. Wayland, implemented as CSD, prevent that. Even in X11 the a CSD application (like gnome-calculator) doesn't work well...

This

Providing the protocol that only handled a subset of features without a real implementation of it that can be integrated into currently DE's is what the biggest mistake was.

[billyswong]

I think that the Windows GDI (and RDP) and X11, had the same fate. They started as vector graphics system capable to work even in bitmaps. Now every application manipulate only bitmaps. The special effect (not only eye candy, think about the anti-aliasing around a font) are implemented passing bitmap back and forth.

RDP / X11 likely work only with bitmap; in fact we could say that VNC was a "precursor" :-)

Let client applications draw the bitmap by themselves is a good idea in 2000-2010 era, when every display is standardizing onto the same sRGB / 60Hz / 96dpi output format. Now when display format diversify and mixed display environment become more common, that earlier choice start to show its cost.

We probably can't go back. I don't want to live in the old days when GUI hang in one program can spread to hang of other programs either. I still support my proposal here: let client applications output multiple buffers catering to each monitor profile. If some programs hog resources too much in such mode, let users force-run them in legacy mode then problem will be circumvented. Such legacy mode can be achieved by either providing a fake standard monitor profile and do the scaling server side, or by locking a window within one monitor, disallowing it to be dragged across monitor boundary.

[blacknova]

I think that the Windows GDI (and RDP) and X11, had the same fate. They started as vector graphics system capable to work even in bitmaps. Now every application manipulate only bitmaps. The special effect (not only eye candy, think about the anti-aliasing around a font) are implemented passing bitmap back and forth.

RDP / X11 likely work only with bitmap; in fact we could say that VNC was a "precursor" :-)

You can pass Direct3D and OpenGL over RDP if necessary. And AFAIK RDP still use WMF/EMF as protocol payload, so it should support text and vector drawing.

[birdie]

You can pass Direct3D and OpenGL over RDP if necessary. And AFAIK RDP still use WMF/EMF as protocol payload, so it should support text and vector drawing.

RDP has always been a vector protocol ( [MS-RDPEGDI]: Remote Desktop Protocol: Graphics Device Interface (GDI) Acceleration Extensions ) and I remember I could use it just fine over a 56Kbit/sec modem connection, something `ssh -X -C` struggled with.

In fact not only it's vector based, it applies the same to video/audio/3D graphics, so those are a lot more efficient as they are decoded and played on the client side and consume significantly less bandwidth.

Again, this feature is not and will never be available under Wayland because it knows nothing but rasterized image buffers. VNC under Wayland will be easier to implement and likely work faster than for X11 and that's it.

[mppix]

I think that this doesn't reflect the reality. A lot of people use Xorg, because wayland.. doesn't give any advantage to justify the switch; more in some case it doesn't support (and likely will never support) modes of working that the people are used to.

I think that an error of the Wayland developers did was to not provide an "equivalent" of X11. From one side they choice to implement a subset of the X11 functionality (the drawing), without supporting input and all other protocol which implement the application interchange of information (like d&d, even if now the things are better). On the other side they coalesced the graphic server with the window manager.

For example I am used to the "focus follow mode" and "raise on click on the title bar". I am comfortable with these because I can put the windows on the screen where and how I want even overlapping and working of all these.

This way of working is implemented in the window manager which must have control of the title bar of all windows. Wayland, implemented as CSD, prevent that. Even in X11 the a CSD application (like gnome-calculator) doesn't work well...

Help me understand:
The display server does not handle inputs and you are saying that is a bad thing? how is spinning out things in dedicated libraries a bad thing?
Also, how is unifying UI elements in a single place - the gui framework - a disadvantage?
Also, I don't see why focus follow mode cannot be implemented with Wayland. You still have a compositor under Wayland that can do things