Fwd: State of network transparency & a possible approach

[Erik De Rijcke]

---------- Forwarded message ---------
Van: Erik De Rijcke <derijcke.erik at gmail.com>
Date: zo 31 mrt. 2019 om 08:23
Subject: Re: State of network transparency & a possible approach
To: Manuel Stoeckl <wayl at mstoeckl.com>


Hi Manuel,

Network transparant wayland has already been done:
https://github.com/udevbe/greenfield
Disclaimer: I am the author of Greenfield.

There are no protocol changes required to make it work. There are however
some other requirements aside from needing access to the underlying raw
protocol (obviously).
Some buffer protocol libraries are opaque to the compositor (wl_shm,
wl_drm, ...). In order to make those work over network, you either need to
completely re-implement (complex) those in a network compatible way with
lots of roundtrips (slow),
or you can keep the current existing implementation and only bother with
the final buffer when it needs to be send. This is how it's in Greenfield.
This however requires some internal libwayland-server state to be visible &
synced between both ends of the network, which is why Greenfield uses a
libwayland-server fork.

In fact you could actually make your idea work on Greenfield with minimal
code changes, if you're ok with web sockets and webrtc data channels. You'd
only need to write a server side compositor daemon that outputs surfaces
using a per-client connection to an existing running native compositor.
There's also work to be done in regards to copy-past/dnd in Greenfield (it
uses a direct p2p connection between clients when transferring content),
although I guess you can defer that until you have a prototype working.

I'm happy to go deeper on the details if you like. I've been meaning to
write it down for some time now anyway.

Erik

Op za 30 mrt. 2019 om 23:36 schreef Manuel Stoeckl <wayl at mstoeckl.com>:

> Hello all,
>
>
> 1.) I'd like to inquire about the state of network transparency for
> Wayland; has there been any notable work since the
> Wayland-over-Wire patches and krh's 'remote' branch?
>
>
> https://lists.freedesktop.org/archives/wayland-devel/2016-February/026933.html
>
> https://cgit.freedesktop.org/~krh/weston/commit/?h=remote&id=7adffe7be46f4cb31c27066332356e4a19b609d5
>
> I recently found an older, similar proposal to the below:
>
>
> https://lists.freedesktop.org/archives/wayland-devel/2010-November/000037.html
>
>
> 2.) My current favorite plan of action to make network-transparency
> feasible without significant breaking changes to libwayland, compositors,
> and toolkits, and hopefully without cementing the details too early:
>
> * Develop a network-transport protocol to communicate buffer changes.
>   (In the worst case, changes can be serialized into a large number of
>   Wayland protocol messages.)
>
> * Develop a pair of applications that act as a server&client, and
>   forward Wayland protocol messages between computers, but also scan
>   the message stream for indications that a shared memory buffer
>   was modified, and inject new network-transport protocol packets
>   to simulate the shared memory updates.
>
> In the long run, the pair of forwarding programs could be absorbed by the
> compositor and/or toolkit, eventually making the network-transport protocol
> a first-class alternative to shared memory/passing file descriptors.
>
> This approach is somewhat work intensive, as many protocols would require
> interception, i.e, wl_shm, wl_drm, wl_data_source, wl_keyboard,
> wl_data_offer, xdg_shell, and a number of the more recent protocols (i.e,
> wlr_data_control, wlr_gamma_control.)
>
> [Note; the above I plan to expand and use as a Google-Summer-Of-Code
> proposal, but given sufficient free time, may implement anyway. Having
> network transparency/shared nothing clients is a one of the main areas
> where Wayland is not yet near parity with X :-(]
>
> Any advice would be welcome.
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190331/2e0425e5/attachment.html>