Wayland?

[twaugh]

Just a general question: does Wayland fit into future plans for TigerVNC, and if so, how?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[CendioOssman]

Hopefully. But it's not something I think anyone has looked into. I am concerned though that the Wayland crowd is ignoring this use case a bit much though and that it will be impossible to do without them having to redesign things. Something that I suspect won't happen easily.

Looking into what's been happening in the area of nested compositors is probably the first step.

[CendioOssman]

Related, I'm also concerned that people might get complacent with the model that Wayland uses and assume that buffer copies are cheap as the GPU does it anyway. So you'll have the crappy performance we see with Gnome Shell for everything once Wayland hits.

[dcommander]

I share your concerns. I'm not sure if Wayland has stopped to consider the problem of remote display at all. This ties into not only VNC but VirtualGL as well.

[dcommander]

My own thoughts on this, based on some discussions at SC'15:
TurboVNC/turbovnc#18

[gaotxg]

gnome-remote-desktop has an implementation of RDP and VNC based upon Wayland and pipewire. Altuough only screen casting and remote control is currently supported, they have plans to support headless mode, maybe an alternative to current X11+VNC+XDMCP+GDM. Perhaps this is a good reference.

[nielsdg]

Just wanted to leave a note here that FLTK has gotten support for wayland since 1.4.0, since that was mentioned in #857.

[q2dg]

gnome-remote-desktop has an implementation of RDP and VNC based upon Wayland and pipewire. Altuough only screen casting and remote control is currently supported, they have plans to support headless mode, maybe an alternative to current X11+VNC+XDMCP+GDM. Perhaps this is a good reference.

From yesterday: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/231782dfeff9dfe3ce8299625bfacd89ee88ab16

[fxzxmicah]

In any case, X11 is doomed, even if it doesn't want to be. It's time to consider moving to wayland.

[dcommander]

@fxzxmicah The fact that there is an issue open means that it is being considered. However, referring to the discussions under TurboVNC/turbovnc#18, kasmtech/KasmVNC#193, and neutrinolabs/xrdp#2637, developing an Xvnc-type solution for Wayland is far from a simple matter. Unlike X.org, you can't simply support one Wayland compositor and expect it to work with all window managers. You would have to specifically support the GNOME flavor of Wayland or specifically support the wlroots flavor, etc. Depending on which flavor you support, that affects your ability to develop a VNC server around it, since the Wayland extensions needed by the VNC server would be different. A project like TigerVNC would potentially have to release a separate VNC server for every different flavor of Wayland compositor.

I'll be brutally honest and say that the Linux community, in general, has treated remote display (especially the large-scale on-demand multi-session variety) as an afterthought for way too long. The decisions made around systemd and GNOME in recent years have limited or eliminated the ability to run multiple simultaneous window manager sessions, which is a key feature of remote display (and one that Windows remote display solutions fully support), and support for remote display in Wayland seems inconsistent at best. I'm not sure what VNC developers are supposed to do about that. An additional issue is the fact that, since the VNC server must be tied to the Wayland compositor, not all Wayland compositors have GPL-compatible licenses.

If money and time were no object, the best of all worlds would be a Wayland compositor designed from the ground up with remote window management capabilities, so it wouldn't require a server-side window manager. (It would implement seamless windows, so you would remotely display individual applications and their windows rather than a remote desktop.) However, the RFB protocol, which was designed around the limitations of 1980s machines, only supports the remote desktop paradigm. As long as we stay within the VNC ecosystem, we're confined to the remote desktop paradigm, which forces us to use a server-side window manager, which creates the aforementioned dilemma regarding which Wayland compositor flavor to support. IMHO, because RFB was designed around the limitations of X11, it would make sense to jettison both at the same time, but good luck with that.

[fxzxmicah]

Sorry, I forgot that this is a server-side and client-side project.
I'm mainly talking about wayland on the client side. I was also aware of the problem on the server side, so I used wayvnc, which works with a specific compositor.

[3ri4nG0ld]

If money and time were no object, the best of all worlds would be a Wayland compositor designed from the ground up with remote window management capabilities

This reminds me of the greenfield project, which implements a wayland composer in a browser.
The bad thing is that it's still very green, but I don't think it will be unusual in the future to see compositors specifically designed for remote use appear.

[dcommander]

This reminds me of the greenfield project, which implements a wayland composer in a browser.

The bad thing is that it's still very green, but I don't think it will be unusual in the future to see compositors specifically designed for remote use appear.

It will be unusual to see them in the open source unless there is sufficient investment in the protocols and other infrastructure needed to make such solutions possible, and that investment needs to occur soon. The RFB protocol, which was designed around the limitations of X, which was designed around the limitations of 1980s graphics systems, is not suitable for such a next-gen solution. There may already be another open remote display protocol that can handle seamless windows, but I am unaware of one.

[fxzxmicah]

It's a little funny to say, now my vnc connection is like this:
remote→wayland→wayvnc→network→vncviewer→x11→xwayland→wayland→local