search

TigerVNC / tigervnc

High performance, multi-platform VNC client and server
https://tigervnc.org
GNU General Public License v2.0
5.06k stars 930 forks source link

Wayland? #158

Open twaugh opened 9 years ago

twaugh commented 9 years ago

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!](https://app.bountysource.com/issues/9912578-wayland?utm_campaign=plugin&utm_content=tracker%2F3557444&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://app.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F3557444&utm_medium=issues&utm_source=github).
CendioOssman commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

My own thoughts on this, based on some discussions at SC'15: https://github.com/TurboVNC/turbovnc/issues/18

gaotxg commented 2 years ago

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 commented 2 years ago

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 commented 9 months ago

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 commented 2 weeks ago

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

dcommander commented 2 weeks ago

@fxzxmicah The fact that there is an issue open means that it is being considered. However, referring to the discussions under https://github.com/TurboVNC/turbovnc/issues/18, https://github.com/kasmtech/KasmVNC/issues/193, and https://github.com/neutrinolabs/xrdp/issues/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 commented 2 weeks ago

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 commented 1 day ago

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 commented 1 day ago

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.