Question about the future of Xorg

Thu Jun 12 13:44:25 UTC 2025

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?

>
>> The virtual framebuffer that people ask for is nice because the apps do
>> not know or care that not everything is displayed - they work just as
>> usual.
>>
>> If you do it at the compositor then an app can attempt to detect whether
>> its output is being recorded by creating an obscured area and monitoring
>> whether it is requested to render to it.
>
> it will be requested to render in frame requests for any reason at all - every
> screen refresh or something else. these do not tell you if you are being
> recorded. the compositor already has all buffers for all windows anyway so as
> long as nothing has updated everything can be recorded by the compositor as it
> already rendered/composited that frame and can use that. clients won't know.

I see.

>
> 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?

>>>> 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.

>>> 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.

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.

best

Vladimir Dergachev

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