[RFC wayland 00/18] Wayland network transparency :)

Wed Feb 10 02:40:11 UTC 2016

My first reaction was that this is the wrong way to do it, but looking at
it a bit I am thinking it really is correct.

This avoids the need for a "proxy compositor" running on the client machine
that does the remote communication. That may be a big selling point since
that compositor is a whole new service that must be set up and running. And
you don't have to invent the whole protocol between the proxy and real
compositor, or debug all the problems where the proxy and real one have
different ideas about what is going on.

This also means that remote desktop to a Windows machine might mean a
Wayland emulator running on the Windows machine, rather than an RDP
emulator running on the client machine.

I am glad you noticed the problem with repeating keys. I think a fix is to
have wayland produce a repeat event, rather than the client doing timeouts.
Even if there is latency, at least the correct number of repeats would be
delivered. All the other logic in handling of the keyboard can remain the
same (ie it can send repeat events whether or not the key actually
repeats), as the order of press/release and repeat would be preserved. I am
still unclear why you cannot add keysym events to Wayland, but they are not
necessary to fix this.

On Tue, Feb 9, 2016 at 5:57 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Tue, Feb 9, 2016 at 8:55 AM, Derek Foreman <derekf at osg.samsung.com>
> wrote:
>
>> I saw a presentation once where someone said that even the simplest
>> implementation of wayland network transparency that just pushed the
>> existing protocol over tcp/ip would still be better than X.
>>
>> Let's test that theory.
>> Hint - application startup time is shockingly fast due to wayland's
>> excellent protocol design, but my poor damage tracking and lack of
>> compression hurts.  Damage tracking is especially bad for anything
>> that doesn't use wl_surface.damage_buffer() - so weston-terminal may
>> be rough but terminology is much snappier.
>>
>
> Kristian came up with a very nifty little image diffing algorithm based on
> a rolling hash that's used to provide compression for the screen recorder.
> (The actual video recorder, not screenshooter.)  You might want to check
> that out.
>
>
>>
>> To try it out (and open a gaping security hole because I've punted on
>> kind of authentication), just add:
>> wl_display_add_remote_socket(display, "foo");
>> to weston right before load_modules in main.  Use at your own risk.
>>
>> That's a literal "foo" because I haven't bothered defining how that
>> name string changes the port.
>>
>> I've written up a short blog post over here:
>> http://blogs.s-osg.org/wow-wayland-over-wire/
>>
>> (It lists other decisions I haven't bothered to make for this trial
>> run.)
>>
>> For those of you that want to view PDF files over the network, EFL's
>> etui viewer comes highly recommended. ;)
>>
>> Derek Foreman (17):
>>   os-compatability: Allow creation of 0 byte anonymous files
>>   os: make set_cloexec_or_close private instead of static
>>   cursor: use wl_os_set_cloexec_or_close instead of local copy
>>   os-compatability: Remove cursor's private os compat stuff entirely
>>   client: Check remaining connection buffer status after each
>>     queue_event()
>>   protocol: Add fd_static type
>>   protocol: Use new fd_static type for keymaps
>>   os: Add wl_os_resize_file()
>>   scanner: Add the concept of "pre hooks"
>>   os: Add wl_os_read() and wl_os_write()
>>   os: Add a wl_os_socket_reuseaddr
>>   connections: Add remote sockets
>>   shm: properly resize remote buffers
>>   connection: support sending the contents of fds as bulk data
>>   connection: Use bulk transfers for fd_static on remote connections
>>   protocol: Add a wl_buffer.transmit
>>   protocol: Add hooks for network transparency
>>
>> Giulio Camuffo (1):
>>   shm: add getters for the fd and offset
>>
>>  Makefile.am               |   5 +-
>>  cursor/os-compatibility.c | 148 -------------------------
>>  cursor/os-compatibility.h |  34 ------
>>  cursor/wayland-cursor.c   |  15 +--
>>  protocol/wayland.dtd      |   1 +
>>  protocol/wayland.xml      |  40 ++++---
>>  src/connection.c          | 150 +++++++++++++++++++++++++-
>>  src/network-client.c      | 269
>> ++++++++++++++++++++++++++++++++++++++++++++++
>>  src/scanner.c             | 117 ++++++++++++++++++--
>>  src/wayland-client-core.h |  10 ++
>>  src/wayland-client.c      | 120 +++++++++++++++++----
>>  src/wayland-os.c          | 162 ++++++++++++++++++++++++++--
>>  src/wayland-os.h          |  19 ++++
>>  src/wayland-private.h     |  13 +++
>>  src/wayland-server-core.h |  13 +++
>>  src/wayland-server.c      | 146 +++++++++++++++++++------
>>  src/wayland-shm.c         |  63 ++++++++++-
>>  17 files changed, 1045 insertions(+), 280 deletions(-)
>>  delete mode 100644 cursor/os-compatibility.c
>>  delete mode 100644 cursor/os-compatibility.h
>>  create mode 100644 src/network-client.c
>>
>> --
>> 2.7.0
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
>
> _______________________________________________
> 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/20160209/a53942dd/attachment.html>