On Wed, 11 Jun 2025, Carsten Haitzler wrote:

On Wed, 11 Jun 2025 11:06:54 -0400 (EDT) Vladimir Dergachev
<volo...@mindspring.com> said:



On Wed, 11 Jun 2025, Carsten Haitzler wrote:

The only misinformation I see comes from Wayland advocates.

well "the lack of virtual screens in wayland" earlier on in this thread was
the newest one i can think of here. that is a complete falsity - wayland
isn't even responsible for this.

Maybe I am missing something here, but I thought virtual screens in X were
implemented by having a large framebuffer, in GPU memory and having CRTC
send a subset of it to the monitor.

it could also be implemented in a fast number of other ways... :) that's how it
was implemented, but it can be implemented in different ways. either way it's
not implemented by wayland - it "implements" nothing. it's the protocol and
libraries to speak that protocol.

the implementations are the wl compositors.

So this is done very close to the hardware, and if Wayland does not do
that who does?

wayland doesn't do it. it doesn't know or care. it would be sway, gnome shell,
kwin etc. etc. - the compositor that might implement this.. and in any way it
likes.

i would personally never implement it as a massive fb. that's too primitive.
i'd just allow panning of windows. i'd keep the wallpaper where it is. my
shelve s(panels) where they are. it achieves the same result - making you think
you have some massive screen that is bigger than the real one able to host
windows that are much bigger. so panning would just be re-rendering 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.

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.

Now that I think of it, should not wayland support part of this functionality already - if you have a GPU that is not connected to any physical monitor, there should be a way to create a framebuffer of any size you desire.


but... it's not a **WAYLAND** issue. it has zero to do with wayland. it is
entirely a feature of a relevant compositor you might use (or not). they could
implement it any way they like, if they implement it at all.

I think it is very much the issue of whatever software (wayland or X, or something else) controls the GPU.

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.

It's really the basic issue of you having control over *your* hardware.

best

Vladimir Dergachev


it's VERY important to know this distinction as it directly leads to who to
complain to or talk to about a feature you want. blaming wayland and
complaining here are totally the wrong places to do that. if youw ant gnome
shell to have this - talk to gnome shell devs. if you want kde to have it ..
complain to kwin devs. if you want sway to have it - talk to sway devs. etc.
etc.

best

Vladimir Dergachev



--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com

Reply via email to