Question about the future of Xorg

[Vladimir Dergachev]

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.

The second app captures the window and part of it is black or something 
else. Not good. I have seen this behavious with zoom and other apps.

This needs to be handled at the protocol level (i.e. Wayland), with 
specific definitions that discuss what happens with partially obscured 
window.

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.


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

>
>> You should be able to render to a framebuffer of *your* choice, and you
>> should be able to configure CRTCs to use framebuffer of *your* choice.
>
> talk to the compositor devs of your chosen wayland compositor, as i keep
> mentioning. wayland has no clue. asking your local bakery for a new hard drive
> is not going to help and the more you complain to them that they don't have a
> hard drive, the grumpier they will get. wayland is a PROTOCOL. it is a
> LANGUAGE. if you went and complained about government policies to the authors
> of the oxford english dictionary is not going to get you anywhere... just
> because your government may happen to speak english to its citizens (for
> example).

You can change a lot by modifying the language..

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.

best

Vladimir Dergachev