Chrome/Chromium's Ozone X11 Code Now Fully Enabled, Old Legacy X11 Code To Be Removed

[pal666]

And you say it based on what?

he probably says it based on all x11 devs switched to wayland development

Are you actively contributing or following either of the projects (Phoronix news articles notwithstanding)?

are you?

Has Xorg become unusable recently?

it was never usable in the first place. also it's orthogonal to it being abandoned

No? Nothing? It's perfectly usable for 99.99% of users out there?

you are pulling numbers out of your ass. neither smartphones nor chromebooks use x11. modern distros switched to wayland by default

Then maybe you could stop expressing your wishful thinking as some sort of truth.

you should practice what you preach

Lastly, X11 compatibility and support which you even more erroneously implicated is not going anywhere in the next 10 years at the very least or ever. There's just too much software based on libX11 which no one will rewrite for shiny Wayland.

all obsolete software is handled by xwayland. x11 support in all non-abandoned software should die

[pal666]

Xorg has none of the issues above and at least to me they all seem crucial. Xorg has its own issues but to be honest nothing that I can recall right away.

all your issues are result of lack of education, but i'm not going to stop you: feel free to maintain xorg yourself while world moves on

[mppix]

Does this means that will be possible to use Wayland on Nvidia cards by Mesa?

It is hopefully on the horizon as EGLStreams still have quite a few limitations even in Gnome, which is probably the most advanced implementation of Wayland on EGLStreams. However, I'm not brave enough to suggest that Nvidia does somthing "common-sense". I can only hope.

[smitty3268]

Linux used to be about the Unix way, reusing libraries and being fast and efficient.

LOL, are you seriously trying to argue that X is fast, efficient, and follows the unix way? It's the opposite of all that.

[Myownfriend]

Wow you skipped a lot of what I said lol

[*]All environments must reimplement the window compositor for Wayland (along with a ton of required features and APIs)

Compositors existed before Wayland. The only difference is that now they can be built using Wayland instead of on-top of X.org. If someone wants to make their own compositor, they are welcome to use wlroots, Vulkan WSI, or whatever else might exist to help them. If they don't then that's their decision.

Also, as far as I know, KWin and Mutter both use the libwayland (server, cursor, egl, etc) and libinput libraries so there is some level of shared code.

[*]Wayland leaves to compositors multiple APIs implementation which means low level utilities must support all of them

Give me an example. This is the third time I'm asking.

[*]All Wayland compositors have their own unique configuration (format)

So? All DEs are going to have settings that only apply to them. If anything, having all those settings together is easier on the user.

Again, the issue you have hear is even slightly annoying is if someone was spending most of their time switching between DEs.

[*]Smaller WMs and DEs (e.g. XFCE LXDE IceWM etc) are left stranded because Wayland compositors are very hard to implement

And? How is this a major problem? These are all built around X11 and are having trouble switching to Wayland because it's different and they have less people working on them. That doesn't mean that Wayland compositors are inherently harder to create than X11 compositors (because again, most DEs use compositors even with X11).

https://wiki.xfce.org/releng/wayland_roadmap

If you look at XFCE's roadmap for supporting Wayland you'll even see that they're considering just using either Kwin or Mutter or using wlroots. It's even mentioned that keeping Xorg support actually removes some of their options.

[*]A Wayland compositor serves as a graphical subsystem and whenever it crashes it brings all GUI applications down with it. Likewise you cannot restart or replace it on the fly. This is specially relevant for tightly integrated WMs like Kwin which has a lot more ways to interact with your session and thus have potentially more ways to crash

There's nothing about Wayland's specification that makes that a requirement.

https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/

[*]Wayland compositors have quite high hardware requirements in terms of support from the kernel and Mesa and might not work if you try to run Wayland on unsupported hardware

Who cares? You mentioned this before and I already responded. There's a lot more to a desktop then Xorg. Applications will always have some level on dependency on features from hardware or drivers that X11 or your compositor might not. For example, you're not going to get Blender, NLEs, games, and a number of other graphical applications running on a software driver from 1994. The fact that X11 has existed since before GPUs means it's going to work on older hardware than new things but that's no reason to keep it around.

Xorg has none of the issues above and at least to me they all seem crucial. Xorg has its own issues but to be honest nothing that I can recall right away.

You're full of shit lol Half these things have to do with potential issues for the migration of smaller DEs. So you don't think the long-staning, will-never-be-fixed issues in Xorg aren't more crucial than those?

[Myownfriend]

lol. do you understand that xwayland is only run from wayland, i.e. if you are running xwayland then you are wayland user and you don't need any app to support x11?

Not only that but even without XWayland installed, it's not like there's no applications that support Wayland natively. A lot of applications that use GTK 3, Qt 5, SDL2, or Electron 12 (and above) can run in Wayland natively. On my end I'm running Firefox, Visual Studio Code, Celluloid, LibreOffice, Discord Canary, Carla, Gimp, OBS Studio, Citra, Duckstation, and all the Gnome apps work natively in Wayland and scale beautifully. Celeste and the PC port of Mario 64 use SDL2 so I can run them in Wayland and Pipewire natively.

[avem]

LOL, are you seriously trying to argue that X is fast, efficient, and follows the unix way? It's the opposite of all that.

Which parts of it may I know? I'm not aware of any "LOL"s in it. Xorg was modularized more than a decade ago, The Xorg process runs separately from your WM and Session unlike with Wayland where WM = Graphics System.

[avem]

Wow you skipped a lot of what I said lol


Compositors existed before Wayland. The only difference is that now they can be built using Wayland instead of on-top of X.org. If someone wants to make their own compositor, they are welcome to use wlroots, Vulkan WSI, or whatever else might exist to help them. If they don't then that's their decision.

You didn't understand my argument at all. It's not about writing a compositor, it's about reimplementing and duplicating a ton of stuff.

Also, as far as I know, KWin and Mutter both use the libwayland (server, cursor, egl, etc) and libinput libraries so there is some level of shared code.

Some level of shared code right, that's why XFCE LXQT and IceWM all refuse to support Wayland even though ostensibly it's just a matter of using some shared libraries, right?

Give me an example. This is the third time I'm asking.

I want to get my systray, screen cast/grab, use DnD under Weston, Wayfire, Sway, etc. Tell me how it all works under these compositors. There's no such issue under Xorg because Xorg's WMs inherit all of this.

So? All DEs are going to have settings that only apply to them. If anything, having all those settings together is easier on the user.

Again, the issue you have hear is even slightly annoying is if someone was spending most of their time switching between DEs.

I want to switch from Wayland Compositor 1 to Wayland Compositor 2, 3, 4, 5 without reading manuals how to configure the other compositors. Tell me how it's done.

I regularly switch between KDE XFCE LXQT IceWM under Xorg and there's no such issue at all.

And? How is this a major problem? These are all built around X11 and are having trouble switching to Wayland because it's different and they have less people working on them. That doesn't mean that Wayland compositors are inherently harder to create than X11 compositors (because again, most DEs use compositors even with X11).

https://wiki.xfce.org/releng/wayland_roadmap

If you look at XFCE's roadmap for supporting Wayland you'll even see that they're considering just using either Kwin or Mutter or using wlroots. It's even mentioned that keeping Xorg support actually removes some of their options.

There are no problems with Wayland. Either you run Gnome or KDE, or you don't use it at all because all other compositors are so incomplete there are basically unusable. Right. I cannot use XFCE right now 13 years after Wayland was released (OK, some say it's 7) and you tell me to read roadmaps? How does reading roadmaps help me run my DE under Wayland?

There's nothing about Wayland's specification that makes that a requirement.
https://arcan-fe.com/2017/12/24/cras...d-compositing/

IT IS WHAT'S HAPPENING RIGHT NOW. IT IS NOT FIXED. IT IS REALLY REALLY BAD. IT DOES NOT AFFECT XORG WINDOWS AND MACOS.

I do not even understand the point of "makes that a requirement". When KWin or Mutter crash right now, all graphical applications die instantaneously. I guess according to you it's a great feature, right?

Who cares? You mentioned this before and I already responded. There's a lot more to a desktop then Xorg. Applications will always have some level on dependency on features from hardware or drivers that X11 or your compositor might not. For example, you're not going to get Blender, NLEs, games, and a number of other graphical applications running on a software driver from 1994. The fact that X11 has existed since before GPUs means it's going to work on older hardware than new things but that's no reason to keep it around.

Aside from people buying new laptops and PCs to run Linux no one cares, right!

You're full of shit lol Half these things have to do with potential issues for the migration of smaller DEs. So you don't think the long-staning, will-never-be-fixed issues in Xorg aren't more crucial than those?

What Xorg issues? No one in this thread has demonstrated a single criticial Xorg issue. None.

I fail to see a single valid counter argument in your reply. It's mostly "I don't care", "No one cares" or simply completely false statements.

[Myownfriend]

You didn't understand my argument at all. It's not about writing a compositor, it's about reimplementing and duplicating a ton of stuff.

Which happens any time you that someone decides to make a new compositor/window manager and it's been a thing before Wayland because X11 is not a compositor. Cinnamon doesn't support Wayland but it's using Muffin which was a fork of Mutter.

Interesting that later on in that post you would bring up Weston and Wayfire when Wayfire runs on top of Weston. Doesn't sound like Wayfire re-implemented everything.

Some level of shared code right, that's why XFCE LXQT and IceWM all refuse to support Wayland even though ostensibly it's just a matter of using some shared libraries, right?

Literally just said that XFCE is intending to use Mutter or KWin directly or use wlroots. The amount of code that DEs share and don't share is a decision that they make, not a requirement. After all the entire point of a new DE is that it's doing something different than others and creating a new codebase for it. How many file managers were created by these projects? We have Nautilus for Gnome, Dolphin, KFM, and Konqueror for KDE, Thunar and XFFM for XFCE, Nemo for Cinnamon, and probably a few more. Did they need to have different file managers for each DE? No. Did they decide to do that? Yes.

I want to get my systray,...There's no such issue under Xorg because Xorg's WMs inherit all of this.

Unless they decide not to use a system tray like Gnome does.

I want to get my ... screen cast/grab...There's no such issue under Xorg because Xorg's WMs inherit all of this.

Generally no DE decides against using the "Print Screen" button on the keyboard. I'm assuming you're talking about xwd though, right?

I love how any and all times that someone defends X11, they bring screenshots or screensharing as if they weren't directly talking about a known vulnerability in X11.

Wayland only allows the compositor to see the contents of the whole screen as a security measure. X11 allows any application to snoop on the frame buffer and inputs of any other application. It doesn't support global hotkeys or screensharing, it's just insecure.

The wiki for xwd even states:

"At the X Window core protocol level, xwd uses the fact that any X client can request the content of an arbitrary window, including ones it did not create, using the GetImage request (this is done by the XGetImage function in the Xlib library). The content of the whole screen is obtained by requesting the content of the root window."

If Xorg fixed this vulnerability then screensharing and global hotkeys would no longer work.

I want to switch from Wayland Compositor 1 to Wayland Compositor 2, 3, 4, 5 without reading manuals how to configure the other compositors. Tell me how it's done.

What are you configuring? Generally when I try out a new DE it will either work right out of the box or I'll just open up it's settings app and set things from there. Again you're trying to make it out like X11 provided any and all functionality to these DEs and that they don't have any of their own settings that are specific to them. Having them all in one place instead of having to configure the DE and X separately is an improvement.

I regularly switch between KDE XFCE LXQT IceWM under Xorg and there's no such issue at all.

What's your experience when switching between those under Wayland? Oh wait, only one of them supports Wayland so you really don't have a basis for comparison.

There are no problems with Wayland. Either you run Gnome or KDE, or you don't use it at all because all other compositors are so incomplete there are basically unusable. Right. I cannot use XFCE right now 13 years after Wayland was released (OK, some say it's 7) and you tell me to read roadmaps? How does reading roadmaps help me run my DE under Wayland?

It doesn't, but if you did, then you wouldn't say half the shit that you say about needing to re-implement everything under Wayland.

IT IS WHAT'S HAPPENING RIGHT NOW. IT IS NOT FIXED. IT IS REALLY REALLY BAD. IT DOES NOT AFFECT XORG WINDOWS AND MACOS.

Why are you bringing up Window and MacOS? Neither uses Xorg or Wayland. Well technically Window's Linux sub-system does but vanilla Windows doesn't. MacOS and Windows aren't reading the Xorg config that you set up in IceWM.

I do not even understand the point of "makes that a requirement". When KWin or Mutter crash right now, all graphical applications die instantaneously. I guess according to you it's a great feature, right?

Nobody said that. This is why I've called you disingenuous. You're deciding to completely ignore that any and all software has it's own architecture with flaws and strength of that architecture.

I love that you're shifting your argument toward "THIS IS THE NOW" while bitching that Wayland compositors might not run on a software driver specification from 1994.

Aside from people buying new laptops and PCs to run Linux no one cares, right!

lmao walk me through that. You buy a new laptop and it has an Intel or AMD CPU and an Intel, Nvidia, or AMD GPU. Since when have those been considered "unsupported hardware"?

What Xorg issues? No one in this thread has demonstrated a single criticial Xorg issue. None.

Let me quote my own post in this topic that was directed at you that you read already. I'll embolden all the times where i mentioned an Xorg issue.

What are you smoking? I've never had to do any more to setup a Wayland session than X11. If anything, the opposite was true because I didn't realize why I was getting tearing and why setting fractional DPI scaling slowed down my mouse sensitivity, made certain applications scale down instead of up, and left applications unreadable. There was also times where one of my monitors wouldn't show anything because it would be set to 30 hertz while my primary monitor is 60 hertz.

I eventually found out I had to Force Compositing in the Nvidia settings to get rid of tearing and that there was no solution at all for fractional scaling and multi-monitor solutions with mixed DPIs and frame rates in X11. When I eventually switched to Wayland (which was a chore only because I have an Nvidia GPU), the experience was fantastic and I haven't had to fiddle with shit. I just set the scaling size, set my primary monitor, and that's it.

And here is me mentioning an X11 flaw in the form of mentioning Wayland's advantages.

Yes. I don't need a DE that runs on a VESA driver because I'm not disingenuous enough to act like that matters in 2021. Unless in your mind you really think that VESA 2.0 driver support is way more important for the Linux desktop in 2021 than fractional DPI scaling, mixed DPIs, mixed frame rates across multiple monitors, solid V-sync, scaled mouse movements, and the security model that Wayland provides.

When I mentioned security I was specifically talking about how it doesn't let applications from snoop on the frame buffers and inputs of other applications. That even applies to remote users. Don't believe me? Check this article out which explains that exploit and others and cites and links to 14 other articles.

https://medium.com/geekculture/explo...s-cc0e2184cece

Assuming you don't ignore this entirely as you tend to do, your response to this will be "That's not a real flaw because no body uses the exploit".

This next quote is about running a Wayland session on unsupported hardware.

Again, what are you talking about? What requirements? When I first ran a Wayland Gnome session on my Nvidia GPU, I didn't have the version of EGLWayland with support for EGLStreams installed. It resulted in my GPU not being used at all and instead everything ran in LLVMPipe. Sounds a lot like I was running Gnome on a GPU that wasn't supported (at least in its GBM backend). In fact, before I figured out about Nvidia-EGLWayland package, I still opted to use a Wayland session over X11 for everyday tasks like web-browsing and stuff because of how much better of an experience it was. Since then it's just gotten better.

I know you read this post because you changed your argument after from "it can't work on a Vesa 2.0 driver" to complaining that you would need to use a Mesa driver to run a Wayland session on unsupported hardware.

I fail to see a single valid counter argument in your reply. It's mostly "I don't care", "No one cares" or simply completely false statements.

That's because you have a tendency to ignore things. What were the false arguments?

And what are those DE-specific APIs that applications need to deal with? This is the fourth time I'm asking.

[tildearrow]

Wow you skipped a lot of what I said lol

He's known for doing that sometimes.
Sadly, he has true points...

Compositors existed before Wayland. The only difference is that now they can be built using Wayland instead of on-top of X.org. If someone wants to make their own compositor, they are welcome to use wlroots, Vulkan WSI, or whatever else might exist to help them. If they don't then that's their decision.

You don't build using Wayland. You build *implementing* Wayland.
Wayland is just a protocol. There is no standard "base" server unlike X.Org where that is the display server.
wlroots and the other libraries are implementation stubs for building a Wayland compositor.

Also, as far as I know, KWin and Mutter both use the libwayland (server, cursor, egl, etc) and libinput libraries so there is some level of shared code.

Some. Not the same as X11 though in where a great portion of the code is shared.

Give me an example. This is the third time I'm asking.

Screen recording, data query and hot keys.
There is no standard screen recording method, other than PipeWire (what if the compositor does not implement it?).
There is no way to query the mouse position or the current keyboard LED state. There is no way to query window names or positions. There is no way to move windows or do stuff in a completely automatic way (like xdotool).
There are real use cases for this, like accessibility, being able to move the cursor to multiple screens (Synergy) or when the keyboard does not have LEDs to indicate the current Num/Caps/Scroll Lock state and so an OSD application is required (I own one of these keyboards).

The Wayland protocol does not specify any mechanisms to do this, in the name of security.
However macOS can do it in a secure way with a permissions system, so why not Wayland?
Instead, you have to implement these things for every compositor, which leads to more work (and good luck if a compositor does not expose these APIs, not even behind a permissions system!).

One user proposed AT-SPI2, but it is rather limited in features...

So? All DEs are going to have settings that only apply to them. If anything, having all those settings together is easier on the user.

What if you want to have a standard configuration that works on all compositors?

Again, the issue you have hear is even slightly annoying is if someone was spending most of their time switching between DEs.

This

And? How is this a major problem? These are all built around X11 and are having trouble switching to Wayland because it's different and they have less people working on them. That doesn't mean that Wayland compositors are inherently harder to create than X11 compositors (because again, most DEs use compositors even with X11).

That's the problem. These window managers are having a hard time to go Wayland due to the need to reimplement everything. Even if you use wlroots and stuff you still have to do a lot of work.

https://wiki.xfce.org/releng/wayland_roadmap

If you look at XFCE's roadmap for supporting Wayland you'll even see that they're considering just using either Kwin or Mutter or using wlroots. It's even mentioned that keeping Xorg support actually removes some of their options.

See how difficult it is to go Wayland?
Now the problem with wlroots is that I've heard it deliberately does not support NVIDIA hardware, because the author of it hates the green brand for not adhering to standards like GBM.

There's nothing about Wayland's specification that makes that a requirement.
https://arcan-fe.com/2017/12/24/cras...d-compositing/

For experimental use, sure; but for daily work use then it is not acceptable to have the display server crash and take the entire session down.
Not like X.Org is any better, but at least it has a very stable codebase and it only crashed on me around 2 times during 6 years of Linux usage (and hasn't crashed again for over 2 years).
KWin Wayland would crash very often (one point it crashed when MOVING the mouse, oh yes Amazing KDE Quality!), and Mutter crashed once after 20 minutes of usage.

Furthermore some compositors (for now) require a total restart when changing settings (looking at you KWin) and if something fails... you know what happens.

Who cares? You mentioned this before and I already responded. There's a lot more to a desktop then Xorg. Applications will always have some level on dependency on features from hardware or drivers that X11 or your compositor might not. For example, you're not going to get Blender, NLEs, games, and a number of other graphical applications running on a software driver from 1994. The fact that X11 has existed since before GPUs means it's going to work on older hardware than new things but that's no reason to keep it around.

Yes, but what about a recovery menu? Worst case the graphics system fails...

You're full of shit lol Half these things have to do with potential issues for the migration of smaller DEs. So you don't think the long-staning, will-never-be-fixed issues in Xorg aren't more crucial than those?

The X.Org/X11 issues are all around security and obsolescence.
The Wayland issues are all around lack of features!