On Thu, 12 Jun 2025, Carsten Haitzler wrote:
On Wed, 11 Jun 2025 14:50:33 -0400 (EDT) Vladimir Dergachev
<[email protected]> 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 - [email protected]
