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

[karolherbst]

I didn't say I have issues with kde, I said you can switch to wayland easily with kde. Certain applications (not kde) have issues when using wayland.

Oh KDE itself also has tons of wayland related issues. I know as I am actually using it and have to deal with those every day. Still need to file bugs for a bunch of those, but claiming that KDE is fine is just not true.

Most of them are just not as important and the benefits of wayland itself still are way more important.

[karolherbst]

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.

X is not network transparent. Not anymore at least. So please stop repeating this nonsense. Everybody claiming that have obviously never used X over the network. Because if they did, they'd know it comes with caveats.

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.

Steam is a big player here actually. They abuse some of XTest to implement their "use the gamepad to emulate the mouse" thing and that discussion was also wild and a deal breaker for them to switch over to wayland as for security reasons you obviously don't want applications to just emulate full input devices, but there you also have those valid use cases.

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

The main reasons is also that sometimes the compositor is also not the proper way of dealing with stuff.

Most of the discussion around X leads into this directions:
1. X is network transparent and we need it (which is just rubbish, Xorg is bad at that, doesn't fully support it and there are better alternatives)
2. X allows every application to capture all input events and record the screen and users shouldn't be treated as children (obviously everybody saying that has no clue about computer security)
3. X is Unix and wayland is not (believe me, X is not Unix, it doesn't do one thing and even if it did, it doesn't do it very well either)
4. X can do everything and wayland can't do shit (fun if brought up in combination with 3. but again, a basic compositor doesn't need to be able to do everything and essentially for Edge or non desktop type devices, you maybe don't want to run X anyway because of security concerns. So having a basic set of APIs to do the fundamentals are a huge win here)

[oiaohm]

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.

O boy how badly wrong you are.

Xwayland is not just another name for X11. Xwayland does not have the X11 compositor extension.

https://www.x.org/releases/X11R7.5/doc/compositeproto/compositeproto.txt

What replaces the composite extension in Xwayland its features are not 100 percent gone. That right Wayland protocol is the Xwayland replacement to the composite extension to X11. The composite extension was not designed to take advantage of zero copy buffers or use file handles. So a X11 application running under Xwayland does in fact get advantage from Wayland being there.

Desktop environments have to be redesigned to take advantage of wayland because a X11 extension most of them used once you switch to a full wayland based desktop is no more.

Zero copy buffers of Wayland can mean when X11 application is full screen it gets the advantage performance of enabling executive fullscreen on old X11 solutions without having to specially mode switch the compositor. Yes the X11 protocol design of how to do compositor means the compositor has to get itself out way not just go hey this buffer from the application is full screen GPU I am doing nothing to it the next frame is this buffer. Of course that old X11 protocol requirement that a compositor has to disconnect itself to get out way causes latency and glitches.

Wayland compositor with Xwayland to run X11 applications does in fact make a huge stack of X11 compositor caused bugs to disappear. Yes running X11 server without a compositor causes a huge stack of tearing issues as well.

Xwayland if we can get all gpu vendors to support in fact offers to be faster and more stable than bare metal X11 solutions for running X11 applications.

Like it or not there is benefit to non ported X11 applications to be on Xwayland instead of bare metal X11 applications in performance and stability due to what the wayland protocol is used to replace in Xwayland and the fact the X11 protocol design of those parts is broken..

[oiaohm]

Steam is a big player here actually. They abuse some of XTest to implement their "use the gamepad to emulate the mouse" thing and that discussion was also wild and a deal breaker for them to switch over to wayland as for security reasons you obviously don't want applications to just emulate full input devices, but there you also have those valid use cases.

When you get to gamescope and later valve developments on testing you see them stop using XTest as much. Proxy compositor in Wayland can in fact do that(yes this is what gamescope is). One big advantage is that gamepad you are using as mouse by a proxy compositor can cease to exist to application as a game pad. Remove the problem of the application processing both the gamepad input and the faked up mouse input.

Yes steam/valve developers resisted the Wayland route at first but now they are going the Wayland route as it come very clear once you work out how to use Wayland design correctly Wayland behaves a lot better than your X11 options including XTest.

Basically you just used out of date information to argue.

2. X allows every application to capture all input events and record the screen and users shouldn't be treated as children (obviously everybody saying that has no clue about computer security)

There are a lot of issues like the above one that you fix by using a proxy compositor instead

https://github.com/freedesktop/evemu

Fun point you don 't need X at all to capture all input events. So users need to capture all input events the compositor not supporting does not mean they cannot.,

3. X is Unix and wayland is not (believe me, X is not Unix, it doesn't do one thing and even if it did, it doesn't do it very well either)

Wayland protocol biggest problem is that it truly does one thing well as in manage the buffers and input devices access for the needs of compositing.

X11 is kitchen sink of just keep on adding more and more features. X11 protocol you cannot find one thing in fact done exactly right.

[karolherbst]

When you get to gamescope and later valve developments on testing you see them stop using XTest as much. Proxy compositor in Wayland can in fact do that(yes this is what gamescope is). One big advantage is that gamepad you are using as mouse by a proxy compositor can cease to exist to application as a game pad. Remove the problem of the application processing both the gamepad input and the faked up mouse input.

Yes steam/valve developers resisted the Wayland route at first but now they are going the Wayland route as it come very clear once you work out how to use Wayland design correctly Wayland behaves a lot better than your X11 options including XTest.

Basically you just used out of date information to argue.


There are a lot of issues like the above one that you fix by using a proxy compositor instead

https://github.com/freedesktop/evemu

Fun point you don 't need X at all to capture all input events. So users need to capture all input events the compositor not supporting does not mean they cannot.,

uhm, the interfaces do emulate input still don't exist and I wasn't saying anything about applications consuming it, but being able to emulate your while input with an application. Like to control your desktop, not doing random game stuff.

The thing Steam does is that it takes your gamepad and with magic button combination it allows you to directly control your cursor. None of that helps and I was talking with "whot" about this issue internally and this also lead to something like this: https://gitlab.freedesktop.org/whot/libei/

Also, to capture raw input events you also need special permissions (atm the input user group) and this is a big problem on its own. Sure you can just grab those, but if you run application sandboxed they can't anymore. But with X this entire idea of sandboxing (be it flatpak or snap or whatever) won't work anyway. The entire situation is a bit messy, but X makes things harder where wayland makes them easier as there are no idiotic APIs to support.

[oiaohm]

uhm, the interfaces do emulate input still don't exist and I wasn't saying anything about applications consuming it, but being able to emulate your while input with an application. Like to control your desktop, not doing random game stuff.

https://wiki.gnome.org/action/show/P...FAccessibility

The reality for accessibility support emulate input has to be sorted out by the compositor. This is going to require updating the at-spi protocol. Please note this is not Wayland protocol problem.

[QUOTE=karolherbst;n1215944]None of that helps and I was talking with "whot" about this issue internally and this also lead to something like this:/QUOTE]
https://gitlab.freedesktop.org/libinput/libei he gave you the older working branch.

So far no one has done a proxy wayland compositor with libei. As gamescope shows proxy Wayland compositors can have quite min latencies. Valve developers have done a proxy compositor injecting input.

Also, to capture raw input events you also need special permissions (atm the input user group) and this is a big problem on its own.

libei project includes a demo todo input input events as kernel uinput again it need sorting out how to grant the permissions. Setting a a dbus service that grants permission to get raw input is not impossible. This would be extending pass functionality you have under X11.

Sure you can just grab those, but if you run application sandboxed they can't anymore. But with X this entire idea of sandboxing (be it flatpak or snap or whatever) won't work anyway. The entire situation is a bit messy, but X makes things harder where wayland makes them easier as there are no idiotic APIs to support.

One of the biggest problems with sandboxing X11 is everything is mixed into one single protocol. So sandbox has all kinds of fun with X11 attempting to see what is input, what is output and so on.

Something that is really simple to forget you can put a proxy wayland compositor before a primary compositor just like you would put it before an application to add features.

Wayland compositors are stack-able without much overhead this adds a very different path to add in missing features.

I guess the idea that your application that controls inputs comes a proxy wayland compositor that only messes with inputs that user can execute at what ever level they want never crossed your mind as a option. This path is not a X11 protocol allowed path but is a wayland allowed this.

[Azrael5]

O boy how badly wrong you are.

Xwayland is not just another name for X11. Xwayland does not have the X11 compositor extension.

https://www.x.org/releases/X11R7.5/doc/compositeproto/compositeproto.txt

What replaces the composite extension in Xwayland its features are not 100 percent gone. That right Wayland protocol is the Xwayland replacement to the composite extension to X11. The composite extension was not designed to take advantage of zero copy buffers or use file handles. So a X11 application running under Xwayland does in fact get advantage from Wayland being there.

Desktop environments have to be redesigned to take advantage of wayland because a X11 extension most of them used once you switch to a full wayland based desktop is no more.

Zero copy buffers of Wayland can mean when X11 application is full screen it gets the advantage performance of enabling executive fullscreen on old X11 solutions without having to specially mode switch the compositor. Yes the X11 protocol design of how to do compositor means the compositor has to get itself out way not just go hey this buffer from the application is full screen GPU I am doing nothing to it the next frame is this buffer. Of course that old X11 protocol requirement that a compositor has to disconnect itself to get out way causes latency and glitches.

Wayland compositor with Xwayland to run X11 applications does in fact make a huge stack of X11 compositor caused bugs to disappear. Yes running X11 server without a compositor causes a huge stack of tearing issues as well.

Xwayland if we can get all gpu vendors to support in fact offers to be faster and more stable than bare metal X11 solutions for running X11 applications.

Like it or not there is benefit to non ported X11 applications to be on Xwayland instead of bare metal X11 applications in performance and stability due to what the wayland protocol is used to replace in Xwayland and the fact the X11 protocol design of those parts is broken..

Xwayland is a waste of resource, it's useless and makes Wayland not efficient. It's necessary to develop pure Wayland linux operating systems. Of course, linux developers must rewrite many programs and desktop environment so to purge xorg from linux. Many years have passed since Wayland has been introduced, too much time has been wasted on a graphical stack which the same main contributor has defined deprecated making Linux operating systems like fossils.

[Old Grouch]

Xwayland is a waste of resource, it's useless and makes Wayland not efficient. It's necessary to develop pure Wayland linux operating systems. Of course, linux developers must rewrite many programs and desktop environment so to purge xorg from linux. Many years have passed since Wayland has been introduced, too much time has been wasted on a graphical stack which the same main contributor has defined deprecated making Linux operating systems like fossils.

XWayland is not useless if it addresses use-cases that are not directly addressed by Wayland per se. You don't persuade people to try something new by telling them what they are used to using every day is useless, as they do not find it so, and you lose credibility.

While you may regard 'the project' to be purging the X Windows System from Linux, the way to do so is to show people how to do the things they say they need using Wayland instead of X; not by being unnecessarily combative. If you are appropriately humble, you might discover previously unrecognised use cases, and participate in developing needed functionality.

The Wayland ecosystem is not finished yet. It never will be. If you help to polish it, more people will be enthused to use it, and become positively engaged. Abusing people is rarely a good method of persuading them to your point of view.

[c117152]

especially when user selected kde with novideo and is blaming wayland for his poor choices

Personally I have sway on one machine and i3 on another (and windows on a third...) so I can't really pick sides

[pal666]

Err.. nope..

yes. it's default, most people just use defaults