Adam Jackson On The State Of The X.Org Server In 2020

[ferry]

You can run separate monitors at different DPI scaling. This is a really huge difference between wayland and xorg (my only experience is gnome wayland via Fedora). And don't try to claim the xrandr hack is equivalent.

Next time I feel the urge to play with my monitor dpi scaling I'll use wayland then.

In the mean time, while getting real work done, I'll leave the settings of my equally sized monitors as they are.

[Mez']

Not quoting your full post, while this answer is some thought I noticed me thinking: Your definition of professional and backwards oriented behaviour seems to be the same. I think you can't accept change to the better, you just dislike change for being a change.

Oh boy. The usual moronic statement when the lack of arguments looms down the road. It's like saying "you're racist" when you don't like a specific sportsman (not knowing the person is fan of another sportsman that completely destroys that assumption). It's a stupid generalization of one context to divert the conversation on a different aspect of the interlocutor and a vain attempt to minimize his serious arguments (vs own futile).

Change can be as good as it can be bad. You need some critical mind to analyze in which category a specific change falls. Why embrace it if you don't believe in it ("yet" in this case)? You can really be negative or wary about one change but it doesn't mean you won't embrace another much more radical change that you believe will change your life for the best.

Plus, here the goal is actually to make the change transparent from the user perspective (much more important than the dev perspective), and until it really is transparent for all workflows and use cases (whoever is responsible for the issues, even indirect), don't expect users to embrace it.

[moilami]

https://drewdevault.com/2019/08/09/DRM-leasing-and-VR-for-Wayland.html

That not exactly true. SteamVR is Wayland compositor picky.and requires you to have AMD graphics because you need accelerated Xwayland. So the reason SteamVR does not work is not a Wayland protocol problem. Instead its particular compositor implementation and not having a jackass video card vendor.

There is some impressive hacking in that.

[oiaohm]

Adam Jackson

So, is Xorg abandoned? To the extent that that means using it to actually control the display, and not just keep X apps running, I'd say yes. But xserver is more than xfree86. Xwayland, Xwin, Xephyr, Xvnc, Xvfb: these are projects with real value that we should not give up.

I'm seriously not understanding the logic here. Aren't all these *the* xserver? To abandon Xorg, the first thing that must die is xserver. How can xserver be killed if all these projects *are* part of xserver? Especially Xwayland?

Adam is not saying the complete xserver.

https://gitlab.freedesktop.org/xorg/xserver/-/tree/master/hw/xfree86

He is saying the xfree86 part of the of the xserver need to go by by. In fact when you build Xwayland, Xwin, Xephyr, Xvnc, Xvfb none of the code from the xfree86 section of the tree is used. xfree86 is only used when you are running xserver on bare metal.

There are a large number of X11 protocol extensions that are not implemented in Xwayland, Xwin, Xephyr, Xvnc and Xvfb. Like a good example of missing is the fact that Xvfb the virtual X11 server to be used for build servers and the like for applications cannot be used to test X11 Windows managers or X11 compositors because the X11 extensions for both are missing. When you go though that list none of the ones in that list support the extensions for X11 compositors.

[Old Grouch]

If Wayland is a better answer than the X Window System, and there is a large amount of valid criticism of Wayland, perhaps Wayland is answering the wrong question, and we would be better in using our energies in determining the right question to ask?

One of the problems of replacing well known and well used software is that the replacements rarely have a complete superset of the capabilities of the system being replaced, and the things missed out are usually important to someone. So you immediately have to decide whether to try and please everyone, or not; and in the case of not, some of the people missing out will be vociferous. It goes with the process.

Microsoft are known for using a lot of effort in preserving backwards compatibility, and even that organisation has to give up. I can well understand that the Wayland developers wanted to start with a clean sheet and do things right, but I would suggest that the migration process from the X Window System way of doing things to Wayland way could have been handled better, and may well be capable of improvement now. Moving a 30-year legacy of use is not easy, even when there are good reasons for it. It is not for nothing that 30-year old COBOL programs are still in use.

There are good arguments for saying the X Window System is not fit for purpose for all the uses it is pressed into serving now. On the other hand, it is certain that Wayland is not fit for purpose for all the things that the X Windows System is used for now. How to bridge that gap is the problem. I would be concerned if the answer is to throw out Wayland and start again.

[oiaohm]

There are good arguments for saying the X Window System is not fit for purpose for all the uses it is pressed into serving now. On the other hand, it is certain that Wayland is not fit for purpose for all the things that the X Windows System is used for now. How to bridge that gap is the problem. I would be concerned if the answer is to throw out Wayland and start again.

This gets close to the right questions.

1) Should X11 Windows System being as many things bundled into 1 project?

Classic one is the arguement for network transparency. Wayland protocol itself does not implement network transparency but the addon waypipe does. Lot of ways it makes more sense to make the network version of the wayland protocol a compositor and client pair like waypipe is so that network parts can be updated independent to the application always because they cannot be accidentally or attentional static linked into the application.

This goes on for issue after issue.

X11 Windows System was document fairly much everything under a single set of protocols. Lot of cases this does not make sense and lead the the insanity of like the xprint protocol and having a basic x86 emulator for running bios images.

2) Next when a person says Wayland does not have X feature did they in fact look how wayland is implemented.

This is repeating error with claiming Wayland compositors would be a lot of coding duplication. Horrible enough the desktop environment made compositors for wayland have more shared code than the X11 compositors the desktop environments made.

To be correct the arguement that Wayland is not fit for purpose for all things may be totally wrong. In fact appears to be totally wrong. The correct statement appears to be "Wayland is not fit for all purposes by itself." The big important but in that statement is nothing says that final solution has to be Wayland protocol with no extras. Wayland with the right extras seams to be suitable for all purposes.

[_ONH_]

I don’t geht the things talked here for computer RHEL 7 an consort seems sufficient, if one needs more one should implement it to be ready when this distributions get eol.

What I see her there is no real need to have the not implemented parts to be implemented in wayland, since no one seems to want to have spent time on it.

Neither wants to implement it themselves or have it implemented paying the $ (kde users complaining someone should do it for free), or pressure the one they payed to deliver what they payed for (Nvidia users). So there are in short just a bunch of imbecile, how are unwilling to contribute to what is needed to get what they want. Backward people should use appropriate sw, and not complaining new is bs.

If distributions using wayland are missing some features, how does it go that enterprises sell products based on this linux systems. Sony seems to have gone doing so, RH seems to have done the same with rhel 8.

[Azrael5]

The end-users or the developers? Because end-users shouldn't have to "commit" to such a thing. It shouldn't be an undertaking for the end-user but a drop-in, seamless replacement. It's not. I could switch, if I switched to a different WM and avoid using apps that are broken in Wayland. Not only might that affect my productivity (which my employer will not like) it might mean learning a new workflow. I'm not going to commit to that, unless Wayland brings something so good it makes it worth it.

Not saying I'll never switch, but I won't switch today. Probably not tomorrow, either.

Of course, the developers. Many problems that occur to end-users are caused because of the poor matching among software and Wayland. Software such as drivers, desktop environment, applications, must be developed so to take benefit from Wayland, otherwise the whole system and/or applications cannot take any benefit from Wayland. Problem is not Wayland but the missed development which whould be aimed to integrate Wayland. When every Linux operating system is pure Wayland based on, the switch will be completed and end-users will be able to get full advantages from Wayland, since Xwayland is the other name of X11.

[karolherbst]

Of course, the developers. Many problems that occur to end-users are caused because of the poor matching among software and Wayland. Software such as drivers, desktop environment, applications, must be developed so to take benefit from Wayland, otherwise the whole system and/or applications cannot take any benefit from Wayland. Problem is not Wayland but the missed development which whould be aimed to integrate Wayland. When every Linux operating system is pure Wayland based on, the switch will be completed and end-users will be able to get full advantages from Wayland, since Xwayland is the other name of X11.

that's just nonsense.

[oiaohm]

What I see her-e- there is no real need to have the not implemented parts to be implemented in wayland, since no one seems to want to have spent time on it.

I think you missed a e I put it in as -e-.

This is the big incorrect presume there are a lot of things to learn from the mistakes of the X11 protocol.

Lets start with network transparency this is one of those parts that makes absolute no sense to implement in Wayland and instead intentionally keep as a third party bit.

Think of all the network security faults X11 protocol has. Then wake up how many of those are locked in stone that you cannot remove the fault without breaking application compatibility. So this is better off done the waypipe route as something next to the Wayland protocol that is strictly not part of it that applications claiming wayland compadiblity have no valid standard reason to include waypipe functionality. Remember waypipe will have to be updated in future security requirements for network protocols will change over the next 30 years.

Notice I said next 30 years. This is how long we need to be looking into the future with Wayland at least.

Lets take another one screen capture people complain about that not being part of the Wayland protocol lets look at X11 that right the X11 protocol has it hard coded that all screens will be joined up into a single image that you can capture. That made sense 30 years ago. That does not in fact make sense with how GPU work today. This is another case you embedded it in the Wayland protocol you will end up digging yourself into the same kind of hole the X11 protocol did when you get 30 years into the future.

There is an advantage to a protocol with third party extra model. Applications claiming to support the protocol have to remain functional with the third party extras missing with just the functionality the third party extras would have provided disabled. You don't want the X11 application issue where it refuses to work at all because some historically bad extension was removed from the server.

Basically everything and the kitchen sink in the protocol as X11 protocol did serous-ally comes back and bites in future.

There are very logical reasons why Wayland protocol looks feature bare. Writing a future stable protocol means you cannot go stupid adding everything.

Some of this history coming back to bite we are starting to see with html as well because the protocol is getting well and truly over grown with no long term planning on how to keep on cutting it back down to size. X11 protocol is not the only example of allow too many bits be added to the protocol the complete thing comes unmanageable.