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
