Question about the future of Xorg

Thu Jun 12 18:01:28 UTC 2025

On Thu, 12 Jun 2025 09:44:25 -0400 (EDT) Vladimir Dergachev
<volodya at mindspring.com> said:

> 
> 
> On Thu, 12 Jun 2025, Carsten Haitzler wrote:
> 
> > On Wed, 11 Jun 2025 14:50:33 -0400 (EDT) Vladimir Dergachev
> > <volodya at mindspring.com> said:
> >
> >>
> >>
> >> On Wed, 11 Jun 2025, Carsten Haitzler wrote:
> >>
> >>>>> the windows on screen with a different offset. keeping other controls
> >>>>> like your pager/shelf/whatever overlayed where they are is far more
> >>>>> useful than having them panned away and off screen.
> >>>>
> >>>> But being primitive is the whole point. The apps render to the large
> >>>> screen as is, and one or more (or none) CRTCs display it on monitors.
> >>>
> >>> the apps don't know or care.
> >>
> >> They do. Consider two apps - one renders into a window that is partly
> >> over the monitor edge, and the other app capture data from that window.
> >>
> >> The first app only renders into the visible area, as it thinks the over
> >> the edge pixels are not displayed.
> >
> > not in a wayland world. the app must render all of its content. doing
> > otherwise would be a bug on the part of the application. the compositor may
> > transform the window - rotate it, resize it... wrap it around the surface
> > of a 3d bunny rabbit. all of the window content should be there because it
> > may be modified and transformed in any way the compositor likes.
> 
> I see.
> 
> Hmm.. But then every window has a huge overhead, even when it obscured. Do 
> you know if anyone run scalability tests? What happens if I have 1000 
> windows?

yes. welcome to a composited world! every window consumes at least 1 buffer.
(width x height x depth). likely 2, maybe 3. there are things you can do.

1. if app stops updating .. trim down to 1 buffer only - thro waway your
backbuffer and spare buffer.
2. for windows that are minimized the compositor could make a scaled down copy
of the buffer e.g. at 1/2 or 1/4 resolution and keep it frozen. it consumes
less memory and is "visible" and usable but low res. the client would have to
participate but the full res buffer could be released at this point until the
app has to update/render again. this is currently not a "thing" in wayland but
one of the areas to explore
3. this is the SAME problem in x with compositing so nothing new. x hasn't
completely fallen apart so wayland won't either. this also  is the case for
apple and windows too - they have to do the same thing. to do compositing you
need buffers for every window. you can as above work on minimizing memory use
but it's not free.

> > if privacy/security is a factor, then it's the compositor's job to enforce
> > that here. apps in general have no access to any other client's windows in a
> > wayland world (unlike x). the only leaks are via a compositor and the leak
> > there is pretty much screenshots (pipewire if implemented - that's dbus) or
> > the new wl screenshot protocol. the compositor can put in this anything it
> > likes as above. it's the compositor's job then to enforce privacy/security
> > by blanking/blurring/hiding content.
> 
> I did not appreciate it was that different. Probably will try to stick 
> with X though a couple of Wayland Kubuntu releases. Unless I get some 
> spare time to fix things.
> 
> Did anyone try porting Neko? Or does it have to be implemented as part of 
> a compositor?

these things can no longer be implemented as arbitrary clients. clients have
zero knowledge of other windows in wayland - they don't see them or know
anything about them. wayland clients are isolated to only knowing their own
windows. they also can't absolute position windows. they can RELATIVE position
one window relative to one of your own windows - that's it. absolute
positioning in xdg shell is not allowed. this is a GOOD thing. so so so much
abuse removed.

so yes - as a result xsnow, xpenguins, neko etc. no longer can exist as apps.
they would be something compositor private only - if that compositor allows.
e.g. vie plugins/extensions etc. this is a good thing. this definitely improves
security/privacy.

> >>>> You don't need the apps to handle the rerendering calls, and the data is
> >>>> always there. For example, you can render a large 8K virtual framebuffer
> >>>> and record it in MP3 file, or view it with x11vnc.
> >>>
> >>> see above. they don't know or care. in a composited world all of a
> >>> window;'s pixels exist in another buffer already - the app already
> >>> rendered them,. the compositor then renders this again when compositing
> >>> where the window is meant to be with whatever transforms/sizes it wants.
> >>> app doesn't need to know or care.
> >>
> >> So, I agree that the app should not care - it should just render as usual.
> >> It is the user that cares and might want to configure his hardware to do
> >> what they want.
> >
> > no - they don't configure the hardware.. they configure their
> > compositor... :) the compositor does with the hw as it pleases to get the
> > effect the user requested. it may be the maximum buffer size the hw can
> > handle is e.g. 4096 pixels wide. the screen is 3840. it would be impossible
> > to do a 7860 wide buffer as the hw literally cannot handle buffer spans
> > wider than 4096. this kind of thing exists in real hardware. the compositor
> > could fake a 7680 wide virtual screen but the display hw could never handle
> > a buffer with spans that wide - so the compositor will do this whoever it
> > can to essentially get the effect... if this is a compositor feature.
> 
> You are right that older cards would have limits on stride, but newer 
> cards are much more generous.

yup - but the point is .. you can implement this without HAVING to have a
literally massive wide single buffer. :) and that is up to compositors to
implement how they see fit. if you want the feature - convince a compositor
author to make it, provide patches or .. write you own "old school x features"
wayland compositor. :) you can also just stick to x too... tho as i've said -
the competition to x is wayland. if it is to survive x needs to move on and
compete. this will mean breaking things.

> >>> anywhere... just because your government may happen to speak english to
> >>> its citizens (for example).
> >>
> >> You can change a lot by modifying the language..
> >
> > then you fail to grasp the problem here nor my analogy. there is only so
> > much i can do to repeat the same thing.
> 
> No, I was just being pedantic in jest ;)

:)

> >> But more on point, I can see how you could modify wayland compositor to
> >> support virtual screens - but then the control app would have to talk to
> >> the compositor to request changes in virtual screen configuration in a
> >> different way than through wayland library.
> >
> > it'd be internal to that compositor. it could just have a config dialog. it
> > doesnt need to be any "control app".
> >
> > example: enlightenment is a wayland compositor. it reads AND writes its own
> > config files. all of its settings dialogs are internal to the
> > wm/compositor. if you want to reconfigure screen setup you use its screen
> > setup dialogs. you click some buttons. it will modify the screen setup. in
> > wayland or in x11 mode. it will save this and restore it. it will remember
> > which screens had what config (based on output+edid data) and restore that
> > when they come back. there are ZERO tools to do this. it's entirely
> > internal all inside the same process that takes care of itself. it;'s the
> > same way gimp has a settings dialog or inkscape does or blender or any
> > other app - they have their own settings dialogs built in and you
> > clicky-pointy to change things and the app responds. enlightenment works
> > the same way. there are no config apps because it doesn't need any.
> >
> > now that is one way to do things. other compositors may work differently -
> > they may implement a special protocol for this and have tools to modify
> > config live on the fly. that protocol doesn't even have to be wayland. it
> > could be they have no protocol, and any config changes require you to edit
> > some file and restart the compositor. in the end it's not a standard
> > wayland protocol that compositors will support. you'll likely find a wide
> > agreement with compositor authors that giving carte blanche protocol access
> > to client apps to modify screen config is a very bad thing and it'll just
> > be NAK'd - if apps need things that may result in different screen setups..
> > then it should be done at a very high level with high level protocol info
> > for windows (surfaces) that then may result in compositors doing something
> > special.
> 
> 
> Yeah, I see it now. I suspect at some point people will try plugin 
> architecture for wayland compositors, because many interesting things can 
> only be done by being within one. Or, make a new protocol that allows 
> plugins to be separate processes.

a common plugin arch won't happen. i can pretty much bet you that. but... what
you may eventually see is a common agreement on what wl compositors SHOULD
support and do to be functional and useful to people and what is really so
super niche that there is no value in the effort to write and maintain such
code for those features.

this is why you can have many wayland compositors. they can compete and address
different userbases and "markets". :)

> Also, before I only had to worry whether Xorg has drivers for my video 
> card, but now it is the question of whether kwin or enlightenment has it.

well they will all use kms and things like mesa and libinput - so you don't
need to care there. the drivers are essentially in the kernel or abstracted by
mesa (opengl, vulkan etc.). so realistically quite a lot has, over time, been
abstracted.

now one area that has NOT been is... 2d accelerators. this has for pretty much
ever been a no-mans land of "no library exists to abstract this" like mesa does
for 3d. in the end most accel has since just ended up punted to the 3d unit.

for 2d rendering accel - it's black magic still and tbh i don't think anyone is
bothering. the only other area is in kms hw plane handling and doing this in
optimal ways. kms abstracts this so it can be done - but different compositors
may do different things.

> best
> 
> Vladimir Dergachev
> 
> >
> >> best
> >>
> >> Vladimir Dergachev
> >>
> >
> >
> > -- 
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - raster at rasterman.com
> >
> 

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com