Wayland and Weston 1.0 released [LWN.net]

Wayland and Weston 1.0 released

Posted Oct 24, 2012 16:42 UTC (Wed) by raven667 (subscriber, #5198)
In reply to: Wayland and Weston 1.0 released by nix
Parent article: Wayland and Weston 1.0 released

It's not the remote display of applications which is being disputed, that is clearly a needed feature and the Wayland team has demonstrated it, it's the desire for the protocol to be _transparent_ and use the same technical mechanism for local and remote display which is being disputed. It's OK if there are different local and remote protocols. In many real practical ways this has already happened with X, the toolkits use accelerated local rendering that tries to bypass as much of the X protocol as possible and remoting is done with NX or xpra or other protocols which are not unadulterated X.

(Log in to post comments)

Wayland and Weston 1.0 released

Posted Oct 24, 2012 17:35 UTC (Wed) by daniels (subscriber, #16193) [Link]

Not to mention the number of clients who use SHM and/or DRI2, which is almost every single one of them. These aren't available on remote machines (or often claim that they are, but they don't work), so you have two codepaths for local vs. remote rendering.

To me, having a proxy compositor which forwards everything on for you and takes care of the details (including deciding which compression method to use) sounds a lot more appealing than that.

Wayland and Weston 1.0 released

Posted Oct 31, 2012 17:19 UTC (Wed) by renox (subscriber, #23785) [Link]

The main point of the dispute IMHO is: should the protocol be designed to work well with remote display (such as XRender's glyph cache mechanism) and then use that for local display plus optimizations such as DRI2, shared memory or should the protocol be only designed to work well locally as Wayland was described initially?

Because if you add in the toolkit/application optimizations for remote display on top of a protocol designed for local use only, it is very likely that there will be interoperability issues (toolkit X with display server Y..), even if 'tookit X with display X' can be better optimized than a generic protocol.

Then again KH has said that he optimized Wayland to reduce the number of RTT, so we'll see, maybe a Wayland proxy will work well even in remote display..