This sort of thing is extremely difficult on X, but very doable on Wayland. I've been thinking about putting broadcast/streaming functionality directly into a compositor, so that your presentations/scenes could be composited separately from your actual windows. Think OBS, but the components/layers of the presentation are Wayland surfaces, and vice-versa, the windows are layers of the presentation. In this sort of system, the compositing can easily happen on the GPU, and can be accelerated like any desktop compositing.
This sort of thing is extremely difficult on X, but very doable on Wayland.
I'd say it is the other way around. With Wayland you'd need buy-in from the entire stack since in Wayland everything needs to be implemented in the compositor. With X all you need is a compositor (not necessary even your window manager, it can be a separate compositor) that ignores the area of one monitor when compositing and instead renders duplicates of the tagged windows there. You can keep using everything else you were already using.
I'm not clear on how this would happen on wayland as I haven't done any development on it yet, but with X it would be tricky since the server still has the window hierarchy state for event routing etc.
If you simply mirrored redirected windows in triplicate all over the place in the compositor, it wouldn't magically make the window manager and X server aware of all those areas as being windows to manage and route events at. You'd just have these ghost windows that can't be directly interacted with as first-class windows.
You'd just have these ghost windows that can't be directly interacted with as first-class windows.
But that is what the GP asked for, not full duplication.
Though if you want duplication it might be possible by creating a window over the duplicated area that the compositor does not render but still grabs all input events that are then forwarded to the original windows via XSendEvent.
I myself have been wondering why no one has made something like a complete software A/V router for this. Plug the output of any application through filters, splitters, muxers, duplicators, whatever, and ultimately out via your chosen sinks. Represent the whole thing in a 2d flowchart like QjackCtl or something.
This is sort of what PipeWire is for, as far as I'm aware. The one advantage of a more monolithic approach (where most of the AV handling is done in the same way as ordinary desktop compositing) is that buffers that originated on the GPU don't need to leave it until very late in the process. If you're really careful, no buffers leave your GPU except encoded complete compositions.
Comments
This sort of thing is extremely difficult on X, but very doable on Wayland. I've been thinking about putting broadcast/streaming functionality directly into a compositor, so that your presentations/scenes could be composited separately from your actual windows. Think OBS, but the components/layers of the presentation are Wayland surfaces, and vice-versa, the windows are layers of the presentation. In this sort of system, the compositing can easily happen on the GPU, and can be accelerated like any desktop compositing.
I'd say it is the other way around. With Wayland you'd need buy-in from the entire stack since in Wayland everything needs to be implemented in the compositor. With X all you need is a compositor (not necessary even your window manager, it can be a separate compositor) that ignores the area of one monitor when compositing and instead renders duplicates of the tagged windows there. You can keep using everything else you were already using.
I'm not clear on how this would happen on wayland as I haven't done any development on it yet, but with X it would be tricky since the server still has the window hierarchy state for event routing etc.
If you simply mirrored redirected windows in triplicate all over the place in the compositor, it wouldn't magically make the window manager and X server aware of all those areas as being windows to manage and route events at. You'd just have these ghost windows that can't be directly interacted with as first-class windows.
But that is what the GP asked for, not full duplication.
Though if you want duplication it might be possible by creating a window over the duplicated area that the compositor does not render but still grabs all input events that are then forwarded to the original windows via XSendEvent.
For a presentation, the non-interactivity might even be more of a feature than a bug.
I myself have been wondering why no one has made something like a complete software A/V router for this. Plug the output of any application through filters, splitters, muxers, duplicators, whatever, and ultimately out via your chosen sinks. Represent the whole thing in a 2d flowchart like QjackCtl or something.
This is sort of what PipeWire is for, as far as I'm aware. The one advantage of a more monolithic approach (where most of the AV handling is done in the same way as ordinary desktop compositing) is that buffers that originated on the GPU don't need to leave it until very late in the process. If you're really careful, no buffers leave your GPU except encoded complete compositions.
https://pipewire.org/