User: Password:
|
|
Subscribe / Log in / New account

Wayland explanations are STILL confusing and worrying users

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 18:07 UTC (Fri) by dlang (subscriber, #313)
In reply to: Wayland explanations are STILL confusing and worrying users by michaeljt
Parent article: The Wayland Situation: Facts About X vs. Wayland (Phoronix)

> ssh simulates a local X server and transparently proxies everything to an X server on a different machine, where it pretends that they are local clients. So from the point of view of server and client, everything looks like it is local, except that X11 features which cannot be proxied are not available.

not quite

SSh forwarding does not simulate a local X server. It simulates a network X server running on localhost.

This is significantly different.

A local X server can use all sorts of shortcuts like shared memory for communication, while a network X server, even one talking to localhost, requires all the same infrastructure that you have to do true network transparency.

the Wayland interface is explicitly NOT able to be sent over a network, it requires local-only interfaces.

The suggested approach of using VNC is the situation where you have some process that simulates the display side and then ships the results elsewhere.

This is exactly the point that concerns so many people who routinely use the existing network transparency.

I remember running Quake over X in the late 90's, the only problem I had was that I hadn't bothered to try remoting the audio, so the sound came from the server two cubes over from me.

Saying that X is unusable for anything is just incorrect.


(Log in to post comments)

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 19:49 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

>SSh forwarding does not simulate a local X server. It simulates a network X server running on localhost.

I stand corrected. Makes sense.

>the Wayland interface is explicitly NOT able to be sent over a network, it requires local-only interfaces.

I haven't looked at the protocol that closely, but what local-only interfaces does it need other than the small matter of the graphics buffers?

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 21:36 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Trying to deal with remote display at the hardware interface level where Wayland operates is probably not helpful, you could make a simple compositor which outputs to VNC but I'm sure we could do much better.

As is pointed out before, modern toolkits often use different rendering methods depending on whether they have local X (with shared memory, DRI) or remote X (serialized, sensitive to round trips), as well as for other platforms (Win32, OSX Quartz). Wayland support is provided by both a standardized protocol and a shared library which toolkits can use which is the canonical implementation of the protocol. The same approach should be taken for remote rendering, providing a standard protocol (maybe based on VNC or SPICE or including both wire formats) and a standard library implementing the protocol which toolkits can use. Then we could have real discussion on the best methods to implement a remote display protocol and what primitives should be made available for toolkit authors.

For example your toolkit, which I remind you can output on multiple type of platforms, knows which regions are scrollable, which are bitmaps, which are clickable, etc. so you can have an optimized, toolkit independent, way of remoting each region. Maybe you can pass compressed bitmaps directly and have them uncompressed on the remote end or cache text glyphs or pre-render scrollable areas. At the very least you can have some primitives that any toolkit can use to find their own clever ways to optimize for remove display.

I guess we need a team as passionate about remote display as the Wayland/X team is about local display. If the work is good enough it might even turn into a cross platform industry standard.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds