Curious what you guys think of wayland.

[Zucca]

Wayland protocols have been extended several times. My guess is that when someone creates good enough implementation of the "primary display" it'll eventually converted to a standard.

My point is that the fragmentation in this case may very well be a good thing. Time will tell...

But all the same systemd is pushing its "standard" (protocol, if you will) for application to do many things "the standard way". Wayland is maybe more careful in this that they'll extend the protocol slowly. Too slowly in many places, IMO.

[stefan11111]

leads to unnecessary fragmenation, broken behaviour

More choices, more fragmentation.
Or would you prefer us all running systemd + GNOME?

AFAIK, with wayland, compositors are forced to implement everything.
This means that an app that works on one wayland compositor might not work on another one.
Forcing compositors to implement everything themselves means that it will be way easier to get things wrong.

Compare this to libc's.
We use a libc because we don't want to implement everything ourselves.
As such, we don't have to write thousands of qsort implementations, or strcpy implementations.
Doing things like this means that application devs don't have to worry about writing things like printf,
and library devs work on a single library, where improvements help everyone who uses that library.

We still don't lose any choice this way.
There are lots of libc implementations, with glibc and musl being the most popular.
And there is nothing stopping people from doing everything themselves.
gcc has the -nostdlib and -ffreestanding flags for this purpose.

Same thing happens with X11.
We work on an X11 server, and all window managers running on top of that server benefit from that.
Say the kde wayland devs make a patch that doubles the performance of the drm driver.
Then only they benefit from that.
Other compositors might try to port the kde patch to their compositor, but that can be very cumbersome,
especially if the patch depends heavily on kde libs.
All other compositors will either not get the benefits from that patch, or would have to spend a lot of
time and effort porting that patch.
On X11, window managers running on top of the X server with that patch would get that speedup for free.

Comparing again with libc implementations.
Would you want all of your programs to write their own printf?
Would you want to be forced to write your own printf everytime you write something?
(proverbial you, not referring to anyone in particular)

Also, I don't get why they merged the window manager with the compositor.
When I play a game, I kill my compositor and disable vsync, so that I get better performance.
Is that not a thing on wayland?

[Zucca]

Compare this to libc's.
We use a libc because we don't want to implement everything ourselves.
As such, we don't have to write thousands of qsort implementations, or strcpy implementations.
Doing things like this means that application devs don't have to worry about writing things like printf,
and library devs work on a single library, where improvements help everyone who uses that library.

We still don't lose any choice this way.
There are lots of libc implementations, with glibc and musl being the most popular.
And there is nothing stopping people from doing everything themselves.
gcc has the -nostdlib and -ffreestanding flags for this purpose.

Good points.
The "libc-like" environment around wayland compositors would be awesome.
We have some of that in the form of wlroots.
However, to my knowledge, the functionalities it provides haven't been standardized, like libc's. Although wlroots has freedesktop gitlab repo, so at some level it's standardized.

But developers can also just ditch wlroots and build their wayland compositors from groud up.

As for compositor and vsync, dunno. I'm about to dig into some interesting adventures... I have 2x 4k displays. Other is 60Hz and the other is 144Hz. I expect problems.

[Anon-E-moose]

As for compositor and vsync, dunno. I'm about to dig into some interesting adventures... I have 2x 4k displays. Other is 60Hz and the other is 144Hz. I expect problems.

Not sure why you would have problems.

I can set vsync on/off, vrr on/off, hdr on/off.

I have a 4k that runs at 60hz (max) and a 2k that runs at 170 (max), they both run together or separate, no big deal.

I can set multiple displays how I want, main display in middle with one on either side or both to one side, rotated or normal.

Edit to add: I certainly have less problems with wayland at 15 vs X at 15 (~1999), X was pretty flakey in those days and extremely fragmented.

[sMueggli]

The issue is that the core Wayland protocol has no support for a primary screen.

Is that the issue? Or does the Wayland protocol have no support for a primary screen, because it is simply not needed? And if you need a "primary screen", wouldn't it be the job of the compositor to "know" the "rank" of a screen?

Stop bullshitting us and yourself. Dual screen setups and more are common place in office environments and as well other places since at least 2 decades.

Good news! I am not bullshitting "us and myself". I am using dual screen setups and I am using them with Wayland and was using them with X11 (Sway and i3). I never needed a "primary screen". I like to have the first workspace on the left screen, but the left screen is not more "primary" than the right screen.

Fun fact for free: I am using also systems with only one screen (curved monitor). Works with Wayland, works with X11, works with Windows 11 and the concept of "primary screen" is obsolete in this case.

Also having more screens in place is quite common for gaming setups, where one screen with lower resolution runs Discord and the other the game.

Yes and this setup works entirely without "needing a primary screen". I am not sure, if "Discord" is wayland-native, but if it is there is nowadays no problem to open "Discord" on the screen where you want to have it open. It is not the job of the "Discord" app to know about "primary or tertiary screen". The app opens with the given resolution at runtime. It is possible that the compositor or X11 has a concept of "primary screen". No need for a Wayland protocol.

Being able to define a primary screen and having working that flawlessly is crucial for many, and common practice nowadays.

One of Wayland's selling points is being able to handle multiple screen setups better than X11 does. So they say.

When I open an application I want it to be started on the screen, that I am actually using. I do certainly not want to open the app "somewhere else" (known as "primary screen").

But it fails to deliver on that simple task, so this is a clear shortcoming by the protocols. Having the compositor figuring that out is just plain bad, because when every compositor needs to figure this out on its own it leads to unnecessary fragmenation, broken behaviour between them and a support nightmare.

For how many Wayland compositors do you give support?

If the Xorg server is able to figure out the "primary screen" why should a Wayland compositor not be able to do the same? Or why is it bad in the latter case? And why is it good to have an unneeded protocol that is limiting the compositor?

If you have a Wayland-native app which does not work on a specific compositor, please open a bug report for the specific compositor (and do not forget to mention that you absolutely need a "primary screen" Wayland protocol because otherwise it "is just plain bad").

[sMueggli]

AFAIK, with wayland, compositors are forced to implement everything.
This means that an app that works on one wayland compositor might not work on another one.

If the app is badly written and depends on compositor internals. Apps should not care about how the compositors are doing their work.

Forcing compositors to implement everything themselves means that it will be way easier to get things wrong.

And forcing compositors to implement nothing themselves means that it will be way harder to get things wrong?

Say the kde wayland devs make a patch that doubles the performance of the drm driver.
Then only they benefit from that.

Let's assume they are able to make Plasma faster. And let's further assume that Plasma was four times slower than another Wayland compositor. In summa Plasma would be only twice as slow compared to the other compositor. And yes, only Plasma users benefit.

Other compositors might try to port the kde patch to their compositor, but that can be very cumbersome,
especially if the patch depends heavily on kde libs.

Yes, also in reality you cannot simply use a random patch that fixes a java.lang.NullPointerException for your own Java code that throws a java.lang.NullPointerException.

[Leonardo.b]

I read some papers about Wayland design VS Xorg design and I see Wayland positively.
Currently I run Xorg because of I'm on the minimal olde-style phylosophy.
Every Wayland compositor requires too much freedesktop cruft.
But I saw some fancy experiments of Wayland on NetBSD and similar niche projects on GitHub, and if they will develop into something solid, I would not mind taking the jump.

[stefan11111]

AFAIK, with wayland, compositors are forced to implement everything.
This means that an app that works on one wayland compositor might not work on another one.

If the app is badly written and depends on compositor internals. Apps should not care about how the compositors are doing their work.

Wayland has the core protocol, that all wayland compositors have to implement, and optional protocols that compositors do not need to implement.
There are also some unofficial protocols that are specific to a compositor, not part of any wayland standard.
As such, there are 10 different ways of doing one thing, and each compositor only supports some of them, or none at all.

On X11 this isn't a problem, no window manager has to implement the RENDER extension, it just gets it for free if the X server supports it.

Forcing compositors to implement everything themselves means that it will be way easier to get things wrong.

And forcing compositors to implement nothing themselves means that it will be way harder to get things wrong?

Yes, if the display server implementation is separate from the window manager, like it is on X, then the X clients cannot get it wrong (because they don't write it).
The display server code is then written by people that only write display server code, and they can focus only on the display server part, and not on the window manager part.
As such, the display server code has more eyes on it, because everyone is using the same code.

Say the kde wayland devs make a patch that doubles the performance of the drm driver.
Then only they benefit from that.

Let's assume they are able to make Plasma faster. And let's further assume that Plasma was four times slower than another Wayland compositor. In summa Plasma would be only twice as slow compared to the other compositor. And yes, only Plasma users benefit.

In that case, kde wouldn't have been four times slower that everyone else, because it would use the same code that everyone else uses.

Other compositors might try to port the kde patch to their compositor, but that can be very cumbersome,
especially if the patch depends heavily on kde libs.

Yes, also in reality you cannot simply use a random patch that fixes a java.lang.NullPointerException for your own Java code that throws a java.lang.NullPointerException.

I don't see what that has to do with anything.

[sMueggli]

AFAIK, with wayland, compositors are forced to implement everything.
This means that an app that works on one wayland compositor might not work on another one.

If the app is badly written and depends on compositor internals. Apps should not care about how the compositors are doing their work.

Wayland has the core protocol, that all wayland compositors have to implement, and optional protocols that compositors do not need to implement.
There are also some unofficial protocols that are specific to a compositor, not part of any wayland standard.
As such, there are 10 different ways of doing one thing, and each compositor only supports some of them, or none at all.

On X11 this isn't a problem, no window manager has to implement the RENDER extension, it just gets it for free if the X server supports it.

So you say it yourself. Wayland has core protocols and the app should just implement the core protocols.

If the app devs choose to implement optional protocols they should also implement fallbacks. The app should work nevertheless.

If the app devs choose to implement unofficial protocols they should also implement fallbacks. Or they should not expect that the app is running "everywhere".

Forcing compositors to implement everything themselves means that it will be way easier to get things wrong.

And forcing compositors to implement nothing themselves means that it will be way harder to get things wrong?

Yes, if the display server implementation is separate from the window manager, like it is on X, then the X clients cannot get it wrong (because they don't write it).
The display server code is then written by people that only write display server code, and they can focus only on the display server part, and not on the window manager part.
As such, the display server code has more eyes on it, because everyone is using the same code.

Isn't one of the Xorg server problems that, although "a lot of eyes" are checking the code, the maintenance is very, very hard? X11 is a mixture of old code, broken code design and a lot of workarounds, that are unfortunately widely used. I dare to say it is easier to maintain and develop a Wayland compositor with a lot less eyes than the Xorg server code with a lot more eyes.

And yes, there are things that work on X11 (because of a broken design and/or a workaround) that are not that easy to get it to work in a Wayland compositor.

I would also like to see what percentage of code is used by the Xorg server in combination with i3 and what percentage of code is actually used by Sway code in combination with wlroots.
The closer this number is to 1, the better. And I have a feeling that this number is much smaller in the X11 variant (but that's just a feeling).

Say the kde wayland devs make a patch that doubles the performance of the drm driver.
Then only they benefit from that.

Let's assume they are able to make Plasma faster. And let's further assume that Plasma was four times slower than another Wayland compositor. In summa Plasma would be only twice as slow compared to the other compositor. And yes, only Plasma users benefit.

In that case, kde wouldn't have been four times slower that everyone else, because it would use the same code that everyone else uses.

If KDE improves shared code that everyone else uses, than the performance gain is also for everyone else, or not? I mean machine code is either executed or not. If machine code is executed, the speed usually does not vary (with the same conditions). If the machine code is not executed with other compositors, then the code is not used by everyone.

Other compositors might try to port the kde patch to their compositor, but that can be very cumbersome,
especially if the patch depends heavily on kde libs.

Yes, also in reality you cannot simply use a random patch that fixes a java.lang.NullPointerException for your own Java code that throws a java.lang.NullPointerException.

I don't see what that has to do with anything.

I just wanted to say that "magic patches" do not exist. If KDE has some elegant way to solve a technical problem with a patch, the dev needs to abstract that patch anyway and can or cannot apply a similar implementation. But it is also common that developers try to do cumbersome things.

[steve_v]

[
If the app devs choose to implement optional protocols they should also implement fallbacks. The app should work nevertheless.

If the app devs choose to implement unofficial protocols they should also implement fallbacks. Or they should not expect that the app is running "everywhere".

Right... So if SDL3 (with its shiny-new wayland-native renderer) wants to go fullscreen on the user's primary monitor (and provide that facility to applications using its libraries), it needs to:
a) Do nothing and hope for the best, because there's no standardised or even generally accepted way to do a fairly simple thing that a large part of the userbase wants.
b) Implement "fallbacks" covering every compositor it could possibly find itself talking to, every unofficial protocol said compositor might support, and various hacks to get internal state from compositors that don't implement a protocol at all.
c) Decide if it's a "Gnome app or not".

The mind boggles. This sounds a lot like "a broken design and/or a workaround" to me, and all because the wayland devs are too stubborn to take the hint from literally every other windowing environment in existence.

What this whole argument appears to boil down to is: "The compositors / apps need to implement this / come up with a protocol / employ workarounds, because *religious reasons*". That's about the biggest copout I've ever heard... And it's far from the first time I've heard it from the Wayland procra^H^H^H^H^H development committee.

When your development model involves more bureaucratic stonewalling and trying to make doing a thing somebody else's problem than it does writing code and getting the thing done, you have a problem.


On a more positive note, @stefan11111 your Xlibre ebuilds are working swimmingly over here. I was writing my own, but you beat me to it.
Better yet, since abandoning my little Wayland experiment and going back to X, a whole host of annoyances have mysteriously vanished.
Clipboard monitoring works again.
Colour pickers work again.
My preferred remote-desktop tools all work again.
My manually specified screen layout and custom modes work again.
Keyboard automation and window manipulation from shell scripts works again.

And best of all? This all just works, regardless of which window manager I load into, without dbus or portals or pipewire or any other nonsense.

[stefan11111]

Wayland has the core protocol, that all wayland compositors have to implement, and optional protocols that compositors do not need to implement.
There are also some unofficial protocols that are specific to a compositor, not part of any wayland standard.
As such, there are 10 different ways of doing one thing, and each compositor only supports some of them, or none at all.

On X11 this isn't a problem, no window manager has to implement the RENDER extension, it just gets it for free if the X server supports it.

So you say it yourself. Wayland has core protocols and the app should just implement the core protocols.

If the app devs choose to implement optional protocols they should also implement fallbacks. The app should work nevertheless.

If the app devs choose to implement unofficial protocols they should also implement fallbacks. Or they should not expect that the app is running "everywhere".

If I'm writing a program with screen capture support, I need to use the multiple wayland extensions that add support for this.
If those are missing, screen capture doesn't work, it can't be done with just the core protocols.

If I want to have global shortcuts, I have to use compositor-specific protocols like https://github.com/hyprwm/hyprland-prot ... uts-v1.xml

On X11, these things just work, regardless of if I'm using dwm or kde.

Yes, if the display server implementation is separate from the window manager, like it is on X, then the X clients cannot get it wrong (because they don't write it).
The display server code is then written by people that only write display server code, and they can focus only on the display server part, and not on the window manager part.
As such, the display server code has more eyes on it, because everyone is using the same code.

Isn't one of the Xorg server problems that, although "a lot of eyes" are checking the code, the maintenance is very, very hard? X11 is a mixture of old code, broken code design and a lot of workarounds, that are unfortunately widely used. I dare to say it is easier to maintain and develop a Wayland compositor with a lot less eyes than the Xorg server code with a lot more eyes.

And yes, there are things that work on X11 (because of a broken design and/or a workaround) that are not that easy to get it to work in a Wayland compositor.

X11 maintenance isn't very hard. People have been working on X servers for 40 years, and we still do that today.
Look at Xlibre, work is being done there.

It's just that the Xorg maintainers decided to keep it more stable and not merge patches,
but there is nothing that would make X server maintenance very hard.

Also, for some reason, there are patches from 2-3 years ago that were applied just to Xwayland, for problems that are also in Xorg.

I would also like to see what percentage of code is used by the Xorg server in combination with i3 and what percentage of code is actually used by Sway code in combination with wlroots.
The closer this number is to 1, the better. And I have a feeling that this number is much smaller in the X11 variant (but that's just a feeling).

The amount of Xorg code used depends on all the X clients you use, not just the window manager.
If all you do is use i3, then not a lot of Xorg code is used.
If, while using i3, you also open a browser, a game, a video, etc, more Xorg code will be used.

If KDE improves shared code that everyone else uses, than the performance gain is also for everyone else, or not? I mean machine code is either executed or not. If machine code is executed, the speed usually does not vary (with the same conditions). If the machine code is not executed with other compositors, then the code is not used by everyone.

If X11 kde devs find out that there is a way for the RENDER extension to work, while making less matrix multiplications, then all X11 users benefit.
If wayland kde devs find out that they can speed up their equivalent of the RENDER extension (if there even is one), then only they benefit.

I just wanted to say that "magic patches" do not exist. If KDE has some elegant way to solve a technical problem with a patch, the dev needs to abstract that patch anyway and can or cannot apply a similar implementation. But it is also common that developers try to do cumbersome things.

On X11, there is no need for that, the patch would get used by all other X users.
On wayland, the kde devs would either have to go out of their way to help other users, which IMO, they are under no obligation, moral or otherwise to do,
or the devs of other compositors would have to look through the kde patches, if they even find out about it, and port it to their own compositor.
This is a lot of extra work for a problem that doesn't exist on X11.

[stefan11111]

On a more positive note, @stefan11111 your Xlibre ebuilds are working swimmingly over here. I was writing my own, but you beat me to it.

I'm glad my ebuilds work for you.
Are you using the ones from https://github.com/X11Libre/ports-gentoo ?
I also have an ebuild in my overlay, but that one is outdated, it was just something to get things working.
You should use the ebuilds from the xlibre overlay.

Also, whoever is writing the gentoo wiki on Xlibre should update it.
There are releases of the Xlibre server, but the wiki says otherwise.

[pietinger]

[...] Also, whoever is writing the gentoo wiki on Xlibre should update it. [...]

Everybody can create an account for our Wiki and update articles ...

[Anon-E-moose]

One more time

Use whatever you want, X, wayland, frame buffer, arcan. xlibre. No one is stopping you from using any or none of these.

Complain all you want about the design of software that you don't even use, but that is uber-pathetic, just sayin'

If you were really serious you would put on your developer shoes and hat and start working on wayland.
Instead I see far too many, sit around while others do the work, on their time, hoping they put in features that "you just can't live without"
self-entitlement seems to be one of those up and coming diseases that are running rampant

https://www.youtube.com/watch?v=Mre-bXXVo18

[pietinger]

[...] But your bitching and whining about what you consider flaws in the design of wayland
on this forum won't make a bit of difference, other than annoy those around you. [...]

I don't like such sentences in our forum ... let people discuss pros and cons of whatever because it's here in the chat.

If you don't want to read the "whining", I recommend avoiding this thread. Your post is even more off-topic than the others.

P.S.: Sound is good.

[sMueggli]

If I'm writing a program with screen capture support, I need to use the multiple wayland extensions that add support for this.
If those are missing, screen capture doesn't work, it can't be done with just the core protocols.

If screen capturing is not part of the core protocols, than it cannot be done with the core protocols. As far as I know screen capturing is currently in the staging phase.

The screen is managed by the Wayland compositor. So it sounds reasonable that the compositor is also handling screen capturing. And there is a thing called "security". It might be a good idea that not every application is able to capture the screen also from other applications. If you know a protocol that is secure and usable for all Wayland compositors, please share it.

If your goal is to have one application that can "screen capture everywhere", then I wish you good luck. If I were to start with a "screen capturing" app (and I try to have security in mind from the beginning) I would start with an app that works on my daily used compositor. And only when I have a stable and working version I would think about a more general approach ("premature optimisation is the root of all evil").

Do one thing and do it well. Do not try to do well on all kind of environments.

If I want to have global shortcuts, I have to use compositor-specific protocols like https://github.com/hyprwm/hyprland-prot ... uts-v1.xml

Let's assume Hyprland is an environment that wants to have global shortcuts (I assume that a window manager may or may not want to have global shortcuts). And Hyprland obviously has a protocol for doing that. Why do you think that this is wrong? Why should Hyprland rely on a probably insecure (but working) solution like X11 shortcut handling? The goal of Wayland is not to be X12 (or X11++), but to take the knowledge and create a better (but different) approach to fill the screens.

On X11, these things just work, regardless of if I'm using dwm or kde.

Yes, on X11 a lot of things just work, be it for legit use cases be it for attackers. And exactly that is also one of the main reasons why an alternative to X11 is needed.

Yes, if the display server implementation is separate from the window manager, like it is on X, then the X clients cannot get it wrong (because they don't write it).
The display server code is then written by people that only write display server code, and they can focus only on the display server part, and not on the window manager part.
As such, the display server code has more eyes on it, because everyone is using the same code.

Isn't one of the Xorg server problems that, although "a lot of eyes" are checking the code, the maintenance is very, very hard? X11 is a mixture of old code, broken code design and a lot of workarounds, that are unfortunately widely used. I dare to say it is easier to maintain and develop a Wayland compositor with a lot less eyes than the Xorg server code with a lot more eyes.

And yes, there are things that work on X11 (because of a broken design and/or a workaround) that are not that easy to get it to work in a Wayland compositor.

X11 maintenance isn't very hard. People have been working on X servers for 40 years, and we still do that today.
Look at Xlibre, work is being done there.

It's just that the Xorg maintainers decided to keep it more stable and not merge patches,
but there is nothing that would make X server maintenance very hard.

Also, for some reason, there are patches from 2-3 years ago that were applied just to Xwayland, for problems that are also in Xorg.

You say X11 maintenance is not hard (I think the Xorg maintainers are looking for more helping hands). But developers like Kristian Høgsberg (DRI2 in X11) have another opinion on that.

Xlibre is still a project in the beginning. And a lot of commits does not mean that a lot of work is done (like a governmental agency: a lot of employees does not mean that a lot of work is done).

People will continue to work on X servers. But I am sure that a lot of the time is used (or wasted?) to work around bugs, design, and security problems in X11.

I would also like to see what percentage of code is used by the Xorg server in combination with i3 and what percentage of code is actually used by Sway code in combination with wlroots.
The closer this number is to 1, the better. And I have a feeling that this number is much smaller in the X11 variant (but that's just a feeling).

The amount of Xorg code used depends on all the X clients you use, not just the window manager.
If all you do is use i3, then not a lot of Xorg code is used.
If, while using i3, you also open a browser, a game, a video, etc, more Xorg code will be used.

In other words: It is impossible to know which code of X11 is used and which not. So whenever you install an X11-based app you have to hope that the Xorg server contains the needed code. And a lot of unused code is installed.

[Anon-E-moose]

If you don't want to read the "whining", I recommend avoiding this thread. Your post is even more off-topic than the others

I keep hoping for intelligent commentary on things like wayland, etc, but I keep being disappointed, terribly disappointed.
All I've seen so far is the same old thing repeated ad infinitum, ad nauseum as if repetition will make a difference. ~le sigh~

[pietinger]

I keep hoping for intelligent commentary on things like wayland, etc, but I keep being disappointed, terribly disappointed. [...]

I understand your disappointment, but as long as two (or more) users are having a decent and (relatively) on-topic conversation, I see no reason for moderation to stop it.

I also understand if you want to vent your frustration for a moment ... the problem is unfortunately that this is contagious ... and then others join in ... and then it becomes a problem (for the moderation) ... and that's why I ... very briefly and superficially ... gave a brief hint (far, far from a reprimand)

[Hu]

If I'm writing a program with screen capture support, I need to use the multiple wayland extensions that add support for this.
If those are missing, screen capture doesn't work, it can't be done with just the core protocols.

If screen capturing is not part of the core protocols, than it cannot be done with the core protocols. As far as I know screen capturing is currently in the staging phase.

The screen is managed by the Wayland compositor. So it sounds reasonable that the compositor is also handling screen capturing. And there is a thing called "security". It might be a good idea that not every application is able to capture the screen also from other applications. If you know a protocol that is secure and usable for all Wayland compositors, please share it.

I think the point here is that screen capture is considered a "useful feature" that ought to be well supported, and so it is frustrating that there is no standardized protocol for doing it. Yes, doing it securely is a good thing, and yes, compositors should be free to apply policy-based decisions to captures, such as deny-all, capture only "approved" windows, or capture the whole screen. However, since it is not a standard protocol, there can exist otherwise featureful compositors that cannot do any form of screen capture at all.

If your goal is to have one application that can "screen capture everywhere", then I wish you good luck. If I were to start with a "screen capturing" app (and I try to have security in mind from the beginning) I would start with an app that works on my daily used compositor. And only when I have a stable and working version I would think about a more general approach ("premature optimisation is the root of all evil").

Do one thing and do it well. Do not try to do well on all kind of environments.

If all environments used standard protocols for all the "obviously useful features", then a capturing application could use a single standardized protocol and do its job well on all environments. This does not mean all environments need to provide all obviously useful features, only that the features they choose to provide should be accessible in a standard way. We have plenty of evidence on the X11 side that some people like minimal environments that lack "obviously useful" features, so I'm not going to argue that all compositors should be held to some minimum standard on what features are offered.

If I want to have global shortcuts, I have to use compositor-specific protocols like https://github.com/hyprwm/hyprland-prot ... uts-v1.xml

Let's assume Hyprland is an environment that wants to have global shortcuts (I assume that a window manager may or may not want to have global shortcuts). And Hyprland obviously has a protocol for doing that. Why do you think that this is wrong? Why should Hyprland rely on a probably insecure (but working) solution like X11 shortcut handling? The goal of Wayland is not to be X12 (or X11++), but to take the knowledge and create a better (but different) approach to fill the screens.

It is not wrong that Hyprland has a protocol for it. It is wrong that Hyprland needs a custom protocol for it. It would be better if there were a standard protocol so that every compositor that wanted to allow global shortcuts could do so, and the applications registering the shortcut did not need to know or care with which compositor they were communicating. We do not need to require that every compositor support global shortcuts, but we should strive for the situation that every compositor that does want to allow global shortcuts will use the same API for accepting them.

[Anon-E-moose]

It is not wrong that Hyprland has a protocol for it. It is wrong that Hyprland needs a custom protocol for it. It would be better if there were a standard protocol

Ignoring for the moment whether hyprland works well with others, other compositors can always grab hypr's protocol and use it.
It's just an extension, if enough people use it, and it's generic enough then it could be pushed towards being a standard.
Not much different than how xrandr protocol got added to X.

The only real complaint I have about new protocols is it's a slow process, painfully slow, though within the last 6 months, they've made efforts to
speed things up by having an experimental area for new non-standard protocols. That's a step in the right direction.

Edit to add:
But the fact that one can write new protocols, is a good feature, it helps standardize.
I'm playing with several compositors, and have pretty much taken to using dwl, with patches as a starting point to having a custom compositor.
It uses a protocol designed for compositors that use tags vs workspaces, and it's been easy enough to extend the protocol
for passing more data that I find I need or would like to have. Then any other software that I come up with can share that protocol.

One thing I don't miss about X, is that when it would crash, it would typically take down my whole system, often requiring a power reboot.
I have compositors that crash, but in the worst case they send me back to the command line, I've never had the system lock up.
And I've noticed lately that firefox is doing something stupid in conjunction with google's AI garbage and the system hangs,
but I also notice that there's a reset function for the gpu, that works well.

[steve_v]

.
Are you using the ones from https://github.com/X11Libre/ports-gentoo ?

Yeah, I switched over to those around the first release. I'm referring to them as "yours" on account of the commit history.

security security security

Well, I guess after these 17 years we have indeed reached peak "security"... I mean If it doesn't exist, it must be pretty difficult to exploit, right?
Meanwhile, real-world exploits of X's outdated and insecure design remain... Distinctly hypothetical.

painfully slow

Indeed. Careful consideration is one thing, shuffling-off due to old-age before we get anywhere near feature-parity is entirely another.

[stefan11111]

Yes, on X11 a lot of things just work, be it for legit use cases be it for attackers. And exactly that is also one of the main reasons why an alternative to X11 is needed.

From your post, I get that, it your opinion, things need to be the way they are because of security.
But what does this security really mean? What are you defending against.

The security concern I see mentioned about X11 (not in this thread, but in general) is the fact that a vulnerability in something else
could allow an attacker to get user-level privileges on a system, after which it could then download and execute some X11 code
that captures key strokes and the screen, and sends that to the attacker.

On single-user systems, like most desktop systems are, I don't see this as much of a risk.
If an attacker gets user-level privileges, I'm already cooked.
They could delete my home directory or exfiltrate any data on my file system that my user has access to.
Whether or not I also lose the rest of my filesystem due to a privilege escalation attack is nothing in comparison to the above.
Another thing they could do is exfiltrate a screen capture of something like a browser.
I'm also not too worried about that, because the browser is by far the largest attack surface on my system,
so that's what a theoretical attacker would first exploit before exploiting my X server.

Another concern is that of suid X. This is a more general concern about running large software as root.
Wayland uses seats to work around suid. X can use elogind to not need suid, so those who want not not run suid X can.

Another concert is that running X over the network can be insecure.
This is true, but most people who run X over the network only do that in their local network.
If there is an attacker in their local network, they have bigger problems.

At least for me, I deem that the risk of running X is negligible compared to the risk of using a browser.
I understand the security concerns of running X and I thing they are mostly theoretical, and worth having for the convenience of using X

@sMueggli What is your threat model that you want to protect against?
Is it something I listed above, or is it something else entirely, that I didn't think of?

[stefan11111]

One more time

Use whatever you want, X, wayland, frame buffer, arcan. xlibre. No one is stopping you from using any or none of these.

Complain all you want about the design of software that you don't even use, but that is uber-pathetic, just sayin'

If you were really serious you would put on your developer shoes and hat and start working on wayland.
Instead I see far too many, sit around while others do the work, on their time, hoping they put in features that "you just can't live without"
self-entitlement seems to be one of those up and coming diseases that are running rampant

https://www.youtube.com/watch?v=Mre-bXXVo18

This is a direct attack on me.
You are no longer criticizing my software choices or my code, you are calling be things like 'pathetic' and 'entitled'.
I have no idea why moderation allowed your comment to stand.

First, about me being pathetic.

Wayland is being aggressively pushed by corporate interests as the future of linux display, yet a lot of people don't like it
or consider it inferior to X11. If X11 supporters don't point out it's flaws, we risk getting this shoved down out throats like systemd was.
The default on most distros is still X11, and I can do something to make sure it stays that way.
One thing is pointing out wayland flaws. Another is bettering X11 (via Xlibre or something else). I do both.

Second, about me being entitled.

You ask me why I don't work on wayland.
I don't work on wayland because I think it is broken by design, and as such, I see no point in working on it.

I do however work on things I consider useful or interesting, like Xlibre, Xorg, kdrive(my fork), tinyx and DirectFB2(not to be confused with the old DirectFB, though I also spent some time on that).
I also maintain a gtk2 fork and ebuild in my overlay for DirectFB/DirectFB2 support (gtk2 can use either X11 or DirectFB/DirectFB2).

Please stop making comments like that. Criticize my code and my software choices all you like, but don't make direct attacks on me when they are not true).
I don't like making direct attacks on people (I criticize their software choices and their code, but never the person), and I hope to not need to make another one like this.
However, when I am attacked like this, I have to respond, because otherwise, people assume that it's true because of my silence.
Comments like yours are no way to talk to people. You later say that you expected intelligent discussion. Is your comment an example of intelligent discussion?

Again, I ask moderation to be more careful about comments such as the one I quoted above.
I'm not a fan of asking for moderation, but if you allow direct attacks, the it's only fair to allow counter-attacks.
Even direct attacks could be sometimes allowed, but only when they are true, and only sometimes.

Also, I ask you to stop making off-topic posts whose only purpose is get try and start arguments.
I'm talking about things like viewtopic-p-8866181-highlight-.html#8866181
What do posts like these add to threads with users asking for support, and others giving it?

Also, if you like the fact that wayland itself doesn't implement much, and lets the compositor do the work, I think that you would like DirectFB2.
There, you don't even have a compositor, you just start apps individually.
Despite the name, DirectFB doesn't just use the framebuffer, it can also, among other things, use eglgbm, which is accelerated.
Look in here to see what can be done with it: https://directfb2.github.io

To me, DirectFB2 looks like what wayland tries to be, but better designed.
There is a lot of work that needs to be done on it to make it usable for most people, but I think it's better designed.

[pietinger]

[...] Again, I ask moderation to be more careful about comments such as the one I quoted above. [...]

The moderation is very careful when it comes to forums such as “Programming” or “Desktop Environments”. In “Chat” we are a bit more “lenient”. Also, we try to help and not punish (you probably remember your frequent USE="-*" and I advised you to create a thread in “Documentation”). I don't mean to reply in place of @Anon-E-moose, but I didn't see his post as a direct attack on you so much as a general complaint about repetition; and yes I've already stopped it and I get the impression all users in this thread have a desire to talk about Wayland in a factual way again. You have now replied to @Anon-E-moose and I think that settles it. We are all human and not perfect.

[Anon-E-moose]

I don't mean to reply in place of @Anon-E-moose, but I didn't see his post as a direct attack on you so much as a general complaint about repetition;

Indeed, pietinger. I didn't respond since there is no sense in trying to rebut someone looking to be offended.