<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>Van: <strong class="gmail_sendername" dir="auto">Erik De Rijcke</strong> <span dir="ltr"><<a href="mailto:derijcke.erik@gmail.com">derijcke.erik@gmail.com</a>></span><br>Date: zo 31 mrt. 2019 om 08:23<br>Subject: Re: State of network transparency & a possible approach<br>To: Manuel Stoeckl <<a href="mailto:wayl@mstoeckl.com">wayl@mstoeckl.com</a>><br></div><br><br><div dir="ltr">Hi Manuel,<div><br></div><div>Network transparant wayland has already been done: <a href="https://github.com/udevbe/greenfield" target="_blank">https://github.com/udevbe/greenfield</a> </div><div>Disclaimer: I am the author of Greenfield.</div><br class="m_-5360902481230876462gmail-Apple-interchange-newline"><div>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).</div><div>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),</div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Erik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op za 30 mrt. 2019 om 23:36 schreef Manuel Stoeckl <<a href="mailto:wayl@mstoeckl.com" target="_blank">wayl@mstoeckl.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
<br>
1.) I'd like to inquire about the state of network transparency for<br>
Wayland; has there been any notable work since the <br>
Wayland-over-Wire patches and krh's 'remote' branch?<br>
<br>
<a href="https://lists.freedesktop.org/archives/wayland-devel/2016-February/026933.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/wayland-devel/2016-February/026933.html</a><br>
<a href="https://cgit.freedesktop.org/~krh/weston/commit/?h=remote&id=7adffe7be46f4cb31c27066332356e4a19b609d5" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/~krh/weston/commit/?h=remote&id=7adffe7be46f4cb31c27066332356e4a19b609d5</a><br>
<br>
I recently found an older, similar proposal to the below:<br>
<br>
<a href="https://lists.freedesktop.org/archives/wayland-devel/2010-November/000037.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/wayland-devel/2010-November/000037.html</a><br>
<br>
<br>
2.) My current favorite plan of action to make network-transparency<br>
feasible without significant breaking changes to libwayland, compositors,<br>
and toolkits, and hopefully without cementing the details too early:<br>
<br>
* Develop a network-transport protocol to communicate buffer changes.<br>
  (In the worst case, changes can be serialized into a large number of<br>
  Wayland protocol messages.)<br>
<br>
* Develop a pair of applications that act as a server&client, and<br>
  forward Wayland protocol messages between computers, but also scan<br>
  the message stream for indications that a shared memory buffer <br>
  was modified, and inject new network-transport protocol packets<br>
  to simulate the shared memory updates.<br>
<br>
In the long run, the pair of forwarding programs could be absorbed by the<br>
compositor and/or toolkit, eventually making the network-transport protocol<br>
a first-class alternative to shared memory/passing file descriptors.<br>
<br>
This approach is somewhat work intensive, as many protocols would require<br>
interception, i.e, wl_shm, wl_drm, wl_data_source, wl_keyboard,<br>
wl_data_offer, xdg_shell, and a number of the more recent protocols (i.e,<br>
wlr_data_control, wlr_gamma_control.)<br>
<br>
[Note; the above I plan to expand and use as a Google-Summer-Of-Code<br>
proposal, but given sufficient free time, may implement anyway. Having<br>
network transparency/shared nothing clients is a one of the main areas<br>
where Wayland is not yet near parity with X :-(]<br>
<br>
Any advice would be welcome.<br>
<br>
<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a></blockquote></div>
</div></div>