State of network transparency & a possible approach

[Simon Ser]

On Sunday, March 31, 2019 12:29 AM, Manuel Stoeckl <wayl at mstoeckl.com> wrote:
> 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.

Hi,

I think Greenfield is relevant here [1]. It can stream a regular
Wayland client to the browser via H.264. (You probably don't want to
send raw frames over the network)

I think a Wayland proxy would be enough. Regular clients talk to the
client part of the proxy, which forwards everything but handles FDs and
wl_buffers in a special way. The data goes through the network, is
received by the server part of the proxy, which then forwards it to
the local Wayland server. That way clients and compositors don't need
to be changed.

Disclaimer: I haven't actually gave this a lot of thought, and I'm sure
this has been discussed countless times before by people who do. :)

Thanks,

[1]: https://github.com/udevbe/greenfield

--
Simon Ser
https://emersion.fr