On Tue, 10 Jun 2025 19:53:40 -0600 Felipe Contreras <[email protected]> said:
> On Tue, Jun 10, 2025 at 1:11 AM Carsten Haitzler <[email protected]> wrote: > > > > On Mon, 9 Jun 2025 19:23:02 -0600 Felipe Contreras > > <[email protected]> said: > > > > > On Mon, Jun 9, 2025 at 5:49 PM Robert Heller <[email protected]> wrote: > > > > > > > > At Mon, 9 Jun 2025 17:13:09 -0600 Felipe Contreras > > > > <[email protected]> wrote: > > > > > > > > You can list a million reasons why Wayland is superior, but people > > > > > still use Xorg, and my bet is that's going to continue to be the case > > > > > for at least a decade, and possibly much more. > > > > > > > > The key part of what Lyude Paul wrote is "But it's also designed for an > > > > era of computing that is much different than how most modern desktops > > > > work...". There are some of "us" who have no use for "modern" desktop > > > > environments. Maybe we actually prefer "old fashioned" desktop > > > > environments. So, we will continue to use Xorg (X11). > > > > > > Of course, but the issue is who is "us". Clearly there's many _users_ > > > that will stick with Xorg, but some _developers_ need to ensure that > > > it keeps working. Who is going to do that in the years to come? > > > > > > That's what I'm trying to find out. > > > > well the way it used to work back in the 80's and 90's is ... this is where > > you stop waiting for someone else to do it and get up and do it yourself. > > Of course, and that's what I've done with multiple projects. But then > political nonsense kicks in and meritocracy is thrown out the window. > Maintainers end up believing they are my boss and are entitled to my > free time. > > Why would I go through that pain again if there isn't a **single** > developer on the project committed to the Xorg server? It does seem > Enrico Weigelt was the only one, so why wouldn't I contribute to > XLibre instead? 1 developer is infinitely more percent than 0. > > > while in my other mails here i'm explaining how wayland works.. i'm doing it > > because i also have fingers in that pie a bit and i know how it works and > > there is a lot of misunderstanding and spreading of misinformation. there > > is bad AND good about wayland. anyone preaching all "bad" is almost likely > > wrong. there is much it improves and does better - sometimes a lot better. > > The only misinformation I see comes from Wayland advocates. well "the lack of virtual screens in wayland" earlier on in this thread was the newest one i can think of here. that is a complete falsity - wayland isn't even responsible for this. it's like saying "well my local bakery doesn't sell me toothpaste! it's unusable!"... it's a bakery. wayland is not a compositor. this is misinformation spread applying the xorg model where gnome/kde/e/whatever sit on top of some mythical wayland "server" and this server should implement all that - it simply is not that at all. it's a complete misunderstanding of wayland and it leads to people moaning on lists like here about wayland features that are COMPOSITOR features and those moans should go to the appropriate compositor of their choice. i've seen this whole misrepresentation of wayland again and again and again over the years. it never goes away. now where i WILL agree and i've said it is there SHOULD have been something like wlroots from the start. there should have been some libwaylandcompositorbuilder.so which abstracts kms, all the plane and mode handling, all the buffer handling as well as the server side of wayland protocols. it should have wrapped xwayland and so on etc. etc. and should have stopped at either buffer to plane assignment and otherwise left rendering alone. this imho was a missing piece (and still is i think - wlroots has its renderer too tightly bound IMHO). maybe that's just how i'd have done it... but it'd have flattened the entry barrier a lot and it would mean there is more shared code amongst compositors where there should be - the common stuff. > You are right that Wayland is not all bad. I was part of the team that > developed the Nokia N9, which shipped with Wayland, and probably was > the first commercial device with it (2011). Daniel Stone was part of > the team. For that use case Wayland was great. :) been on that train too on the tizen side. :) > But for my laptop it's not, Xorg is superior in every way. That's my > opinion, and that's the opinion of many people who still use Xorg and > are not going to stop any time soon. there's good reason to believe that wayland could be more power efficient on such devices as unlike x, it can much more easily take advantage of hw layers/overlays for window content thus avoding a gpu composition cycle for updates of some window. this is one of the areas i'd suggest xorg needs an extension for. the way i'd do it is adding to the x composite overlay window. more specifically i'd keep the current one and offer an api to query N extra overlay windows - any rendering to these (via core x protocol or via dri buffer swaps) point that plane to that buffer (or for core protocol create a buffer and just fill it). mapping and unmapping that plane window enables/disables the plane. being able to configure the window (move/resize) would configure the plane too. catche here: some hw won't allow this. some hw won't allow re-stacking of the planes (they are fixed). some planes may only support a subset of buffer formats. some planes can also scale, rotate individually (separate from xrandr global control) etc. - do we expose this, if so how? either way this would provide access to hw planes and help plug this gap. compositors then can add support for it over time. anyway - main point is ... there is no reason this can't be improved in x. it won't solve the "x comes with a lot of baggage" problem that wayland gets rid of in one big go. but getting rid of that comes with side effects as already discussed. wayland does have shortcomings > > anyway - my point is... if xorg just goes into maintenance only mode - at > > best, you're going to just keep a system that needs work on life support. if > > you want to truly keep it alive it has to not just be maintained but moved > > forward. new extensions, re-jigging of old extensions and even core protocol > > with the understanding that you WILL break some things as you go and you are > > judicious about how you do that, then x has a chance to really survive. > > I personally don't need new features, I just need it to work as it has > always worked on top of newer linux kernels. That's it. > > But yes, newer generations are going to want new features and if those > aren't implemented Xorg is going to become more and more obscure. > That's not something I particularly care about, I just need it to > work. that;'s what you'll need for long term health. that's why i bring it up. if it's done on xorg or on xlibre - doesn't much matter bvut otherwise it is postponing the inevitable. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected]
