Question about the future of Xorg

[Carsten Haitzler]

On Tue, 10 Jun 2025 19:53:40 -0600 Felipe Contreras
<felipe.contreras at gmail.com> said:

> On Tue, Jun 10, 2025 at 1:11 AM Carsten Haitzler <raster at rasterman.com> wrote:
> >
> > On Mon, 9 Jun 2025 19:23:02 -0600 Felipe Contreras
> > <felipe.contreras at gmail.com> said:
> >
> > > On Mon, Jun 9, 2025 at 5:49 PM Robert Heller <heller at deepsoft.com> wrote:
> > > >
> > > > At Mon, 9 Jun 2025 17:13:09 -0600 Felipe Contreras
> > > > <felipe.contreras at gmail.com> 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 - raster at rasterman.com