Question about the future of Xorg

[Vladimir Dergachev]

On Wed, 11 Jun 2025, Carsten Haitzler wrote:

> On Wed, 11 Jun 2025 11:06:54 -0400 (EDT) Vladimir Dergachev
> <volodya at 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 - raster at rasterman.com
>