LWN: Comments on "Canonical reveals plans to launch Mir display server (The H)"

Bad NIH, good NIH

flussence — Mon, 20 Apr 2015 17:25:24 +0000

> Preferably I'd also like to figure out what problem Wayland is actually trying to solve, which I haven't yet.

The problem is getting thirty-plus years of X11 extensions to work together properly while fixing all the hacks, cracks and seams.

On X11, in 2015, you still can't do simple things like telling ffmpeg to video grab the contents of a window. Multi-GPU rendering support is barely emerging now, and a decade behind other OSes. You can't relocate a window started in /usr/bin/Xorg to another computer; it's a pain in the ass to drag it from one graphics card to another on the *same* computer — Windows *98* could do that! And you're probably still running all this pre-Internet codebase with setuid-root privileges.

Moving the goalposts

renox — Mon, 20 Apr 2015 08:40:24 +0000

Given that Mir is a clone of Wayland, you'll have to explain the 'going in the wrong direction' part..

Bad NIH, good NIH

bandrami — Mon, 20 Apr 2015 03:08:42 +0000

> Nobody needs or wants X servers for Windows, Mac OS or Android.

Err... other than those of us who use them (admittedly I haven't done it on Android)

> It doesn't run everywhere. Android doesn't use it, Firefox OS doesn't, Tizen doesn't, Mac OS X and iOS don't

Apple went to the trouble of developing their own X server.

> That will come for Wayland as well, it's just a matter of time.

Well, I'll *consider* trying Wayland when it lets me do the things I can do today with X11. (Preferably I'd also like to figure out what problem Wayland is actually trying to solve, which I haven't yet.)

Honestly, it's the same issue I have with Systemd: it may be awesome at solving the problems it's addressing, but these are problems I don't have, so I see no need to change (thank you, Slackware...)

Moving the goalposts

bandrami — Mon, 20 Apr 2015 02:54:36 +0000

> Wayland needs the help and for shuttleworth to run off and spend his limited resources on yet another fork is insanity

No, insanity is using limited resources helping a project you think is going in the wrong direction.

Yet another Wayland thread

Serge — Sun, 17 Mar 2013 11:11:27 +0000

> This makes it an IPC, by definition.

Hm. But it allows you to communicate with compositor only, and using protocol/wayland.xml messages only. Among others you also have a weird definition for "IPC"...

> Check the source code. There are no restrictions on message content.

protocol/wayland.xml is the source code of the protocol.

> Weston is a reference implementation of the Wayland compositor. Which is a separate piece from Wayland protocol or library. What do you not understand?

Ah! So what you called "Wayland" was libwayland-client (or was it libwayland-server?) I wonder, when you said "X" were you talking about libX11?

Anyway, I understand you now. Yes, libwayland allows you to send messages that are not part of the Wayland protocol, and you don't have to rebuild libwayland to send custom messages.

But that does not change much. In X world if you want your app displayed in some special way in your dockbar you need to patch you app and your dockbar, but you don't have to patch WM or X-server. In Wayland world you need to patch your app, dockbar and compositor. And it will work on your compositor only.

Yet another Wayland thread

Cyberax — Sun, 17 Mar 2013 10:05:30 +0000

> The link you posted states that Wayland is a protocol and Weston is implementation. Have you read it yourself? ;-)
Weston is a reference implementation of the Wayland compositor. Which is a separate piece from Wayland protocol or library. What do you not understand?

Yet another Wayland thread

Cyberax — Sun, 17 Mar 2013 10:04:24 +0000

> "Wayland is a protocol for a new display server", "The wayland protocol is an asynchronous object oriented protocol", "The interfaces, requests and events are defined in protocol/wayland.xml".
This makes it an IPC, by definition.

> I don't see anything about "IPC" or applications that "can use this IPC to exchange any type of data".
Check the source code. There are no restrictions on message content.

Yet another Wayland thread

Serge — Sun, 17 Mar 2013 09:45:54 +0000

> http://cgit.freedesktop.org/wayland/wayland/tree/doc/Wayland - enjoy... What exactly do you not understand?

"Wayland is a protocol for a new display server", "The wayland protocol is an asynchronous object oriented protocol", "The interfaces, requests and events are defined in protocol/wayland.xml". I don't see anything about "IPC" or applications that "can use this IPC to exchange any type of data".

> That Wayland is both the name of a protocol AND its default implementation (i.e. Wayland)? Or that Wayland protocol can be used to carry app- and shell-specific data?

The link you posted states that Wayland is a protocol and Weston is implementation. Have you read it yourself? ;-)

Yet another Wayland thread

HelloWorld — Sat, 16 Mar 2013 20:24:42 +0000

Wayland is both a protocol and a library implementing that protocol. Weston is a compositor based on the Wayland library.

Yet another Wayland thread

cortana — Sat, 16 Mar 2013 14:33:29 +0000

I don't mean to sound thick, but I thought the reference implementation was called Weston?

Bad NIH, good NIH

Cyberax — Sat, 16 Mar 2013 09:08:02 +0000

But it's not a part of my X server.

Waaahhhh! X encourages fragmentation!

Yet another Wayland thread

Cyberax — Sat, 16 Mar 2013 09:06:37 +0000

http://cgit.freedesktop.org/wayland/wayland/tree/doc/Wayland - enjoy...

What exactly do you not understand? That Wayland is both the name of a protocol AND its default implementation (i.e. Wayland)? Or that Wayland protocol can be used to carry app- and shell-specific data?

Yet another Wayland thread

Serge — Sat, 16 Mar 2013 07:46:29 +0000

> Basically, Wayland provides a way for processes to communicate using a special form of IPC. Applications can use this IPC to exchange any type of data they want. Wayland itself also provides some services (described in wayland.xml) using this IPC.

Looks like you have your own understanding of the word "Wayland". Can you give me a link to the specification of THAT Wayland?

Bad NIH, good NIH

Serge — Sat, 16 Mar 2013 07:22:43 +0000

> That's an extension, not the X protocol itself.

In X world extensions are part of the X11 protocol. For example this particular extension is part of X11R6.9, you can see that in its URL.

Bad NIH, good NIH

HelloWorld — Sat, 16 Mar 2013 00:15:33 +0000

Yes, that's true. It also doesn't matter at all.

Yet another Wayland thread

Cyberax — Fri, 15 Mar 2013 16:09:58 +0000

> In Weston/Wayland you MUST recompile the compositor. Your program links with compositor, they share protocol. People won't be able build it until they update the compositor too.
Weston/Wayland? What is it?

Wayland and Weston are completely separate and independent components.

Yet another Wayland thread

Cyberax — Fri, 15 Mar 2013 16:08:03 +0000

> Then what're Weston and QTWayland?
Weston is a _compositor_. I.e. it's something like a WM in X world. And QTWayland is simply a name of QT integration with Wayland.

> I still don't understand what you mean.
Basically, Wayland provides a way for processes to communicate using a special form of IPC. Applications can use this IPC to exchange any type of data they want. Wayland itself also provides some services (described in wayland.xml) using this IPC.

> It's like saying that you can use GIF to store MP3 data just because you can put mp3-file to the directory with gif-files.
No. I'm saying that I can use Dropbox to synchronize not only Dropbox user manual but also GIFs and MP3.

Bad NIH, good NIH

Cyberax — Fri, 15 Mar 2013 16:04:17 +0000

That's an extension, not the X protocol itself.

Yet another Wayland thread

micka — Fri, 15 Mar 2013 09:37:46 +0000

> But in Wayland world you have to spend those 20 years again to reimplement them all from scratch.

For my part, I will assume that wayland devs are intelligent beings that are even able to make use of all the hard word that's been done in the past.

Yet another Wayland thread

Serge — Fri, 15 Mar 2013 09:09:08 +0000

> More like saying you can use TCP to send HTTP request.

TCP has "data" section that is designed to carry another protocol. But you won't find a placeholder for another protocol in wayland.xml.

Bad NIH, good NIH

Serge — Fri, 15 Mar 2013 09:01:08 +0000

> No, but many repeated runs do bring it down to 0.109s in the best case. I think this is an example where the first case is the relevant one though, because that's what you'd experience in real use.

It depends on what do you want to benchmark. If you're just curious "how fast would it be next time I try" then yes. But if your goal is to compare two programs then you must reduce impact of all other obstacles, i.e. cpu throttles, disk cache, memory/swap, other programs running, etc.

> I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.

I was just trying to say that "core protocol imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips)" is not true. Slow startup is not X11 issue when running locally. Wayland only makes things worse. Applications would ofter start slower on Wayland because they're expected to talk to hardware, which requires additional steps for hardware initialization.

As for remote startup it's not that fast because of software, not because of protocol limitations. For example it could be much faster if xterm was sending requests in batch instead of waiting for response every time before sending another request. But people are lazy... They don't like optimizing things. But they like rewriting things from scratch somewhy. It's not a problem of X11 protocol, it's a human problem.

Yet another Wayland thread

Serge — Fri, 15 Mar 2013 08:27:06 +0000

> When you decide to use a new hint, you change the window manager to interpret it and then use it in the client. So you must recompile the WM. X provides the communication transport.

You CAN recompile WM, but you don't have to. Your program and WM are independent. You can build your program on another WM and it will work there, just your hint will be ignored.

> In wayland world, all this happens between the client and the compositor. If you must add a hint, you change and recompile the compositor.

In Weston/Wayland you MUST recompile the compositor. Your program links with compositor, they share protocol. People won't be able build it until they update the compositor too.

> In both cases, the work to add a new hint is exactly the same.

You forget about the first difference. For the last 20 years most hints were already added, standards for them were already written and implemented in WMs. But in Wayland world you have to spend those 20 years again to reimplement them all from scratch. And you cannot reuse those standards, because Wayland does everything differently.

So in wayland world in addition to the work of adding a new hint you have to also do a lot of work to add all the old hints. It's a weird world...

Yet another Wayland thread

micka — Fri, 15 Mar 2013 07:44:19 +0000

> It's like saying [...]

More like saying you can use TCP to send HTTP request.

Yet another Wayland thread

Serge — Fri, 15 Mar 2013 07:17:40 +0000

> Actually, Wayland is also the name of the implementation.

Then what're Weston and QTWayland?

> You CAN use Wayland protocol to pass private messages just fine. No recompilation required.

I still don't understand what you mean. Protocol is a document, messages that are not in scope of that document are not part of the protocol. So you cannot send your private messages unless your "private messages" are part of the protocol. Technically you can send them through the same socket, but it won't make them part of Wayland protocol.

It's like saying that you can use GIF to store MP3 data just because you can put mp3-file to the directory with gif-files.

Bad NIH, good NIH

Serge — Fri, 15 Mar 2013 07:15:34 +0000

> Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.

http://www.x.org/releases/X11R6.9.0/doc/render-protocol.txt

Yet another Wayland thread

Cyberax — Thu, 14 Mar 2013 17:33:29 +0000

Actually, Wayland is also the name of the implementation.

And I was answering to this:
>Second: on X you don't have to patch X server to add the support for your new hint, wayland protocol is not so flexible.

You CAN use Wayland protocol to pass private messages just fine. No recompilation required.

Bad NIH, good NIH

Cyberax — Thu, 14 Mar 2013 17:31:57 +0000

Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.

Bad NIH, good NIH

nye — Thu, 14 Mar 2013 11:24:10 +0000

>Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?

No, but many repeated runs do bring it down to 0.109s in the best case.
I think this is an example where the first case is the relevant one though, because that's what you'd experience in real use.

To be fair, I don't know if the video device and driver in use have any bearing on this, but just in case it does it's worth noting that I'm running on a laptop with Intel integrated graphics, where I have historically found the quality of both hardware and driver ranges from 'awful' to 'unspeakably awful'.

> If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:

I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.

Bad NIH, good NIH

nye — Thu, 14 Mar 2013 10:59:35 +0000

>You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.

"Screen 0 (sub-pixel order Unknown)"

i915 driver FWIW.

Bad NIH, good NIH

Serge — Thu, 14 Mar 2013 08:35:03 +0000

> cyberax@whale2:~$ xrandr --verbose
> SZ: Pixels Physical Refresh
> *0 1024 x 768 ( 260mm x 195mm ) *60
> ...
> Yeah, robust X protocol and all that....

Ha-ha, that was fun. Either you have done that on purpose, or you're testing that on a server back from 2005. :-) You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.

Xrandr is just a tool to request that information. Xdpyinfo is another one. X-server knows about subpixels and uses them for a loooong time.

> Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).

Why do you think it won't work? Hah! Try Wayland with legacy NVidia driver (hint: it doesn't work)!

> See "enum transform" and various related events and requests

Have you seen that yourself? It's just display rotation, similar to xrandr, not the surface rotation done by compositor.

Yet another Wayland thread

Serge — Thu, 14 Mar 2013 06:02:36 +0000

> Wayland can be used to transport private messages (i.e. new hints) just fine without any recompilations.

I'm not sure what you're trying to say, but Wayland is a protocol. It cannot transport private messages and you cannot compile it.

Bad NIH, good NIH

Serge — Thu, 14 Mar 2013 05:48:29 +0000

> You (or xterm) are doing something very wrong.

You can check that using x11trace tool. Most of the time is taken by sending fonts and other settings. That increases startup time, but makes it work faster, because it does not have to send images, it can reference fonts on the server side.

Xterm is smarter than most people think. It has configurable fonts, colors, hotkeys and many other options. For example to see xterm menu hold Control+Left/Right/Middle mouse button. But the point is that those settings are stored on a server-side (XResource), and xterm reads them all from server during startup.

Some DEs are using that. For example on KDE xterm colors should match your theme, does not matter what host you start xterm from. That's the server-side themes in action. Nobody remembers them any more... (sigh)

Bad NIH, good NIH

Cyberax — Thu, 14 Mar 2013 05:45:24 +0000

> Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)
Yep. Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).

Of course, your app can also read display EDIDs and parse them. Through the X protocol! But that kinda says that you should probably stop doing it.

> Run `xrandr --verbose` and see "Subpixel" there.
Lessee:

>cyberax@whale2:~$ xrandr --verbose
> SZ: Pixels Physical Refresh
>*0 1024 x 768 ( 260mm x 195mm ) *60
>Current rotation - normal
>Current reflection - none
>Rotations possible - normal
>Reflections possible - none
>Setting size to 0, rotation to normal
>Setting reflection on neither axis

Yeah, robust X protocol and all that....

> Indeed, it's a surprise, could you point me to that part of the Wayland protocol?
See "enum transform" and various related events and requests in http://cgit.freedesktop.org/wayland/wayland/tree/protocol... .

Bad NIH, good NIH

Serge — Thu, 14 Mar 2013 05:43:45 +0000

> $time xterm -e /bin/true
> real 0m0.359s
> user 0m0.032s
> sys 0m0.036s

Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?

Anyway, your samples confirm that running application remotely is slower than running it locally. That was obvious even without testing. :) If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:

$ time xterm
real 0m0.066s
user 0m0.024s
sys 0m0.008s

$ time weston-terminal
real 0m0.095s
user 0m0.064s
sys 0m0.028s

But even that test does not necessary mean that X is faster than Wayland. It just means, that xterm starts faster. Both times are good enough. And X11 is not a bottleneck for faster program startup time. If you actually need faster startup over network right away you can try winswitch.org/xpra.

PS: When benchmarking some soft do multiple tests and select the best result. Also don't forget to switch cpufreq governor to "performance" otherwise you're benchmarking your governor, not your soft.

Bad NIH, good NIH

Serge — Thu, 14 Mar 2013 05:38:18 +0000

> Nope. X protocol knows nothing about subpixel order. Wayland does.

Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)

> Xranrd in this case is a cop-out because it's not universally available.

Run `xrandr --verbose` and see "Subpixel" there. Now think, if xrandr gets information from X-server then X-server knows about subpixels, and X11 protocol is able to transfer that, right? Just read the protocol if you still don't believe me.

> Wayland exposes the surface orientation to applications (surprise!)

Indeed, it's a surprise, could you point me to that part of the Wayland protocol?

A bit lopsided

heijo — Thu, 14 Mar 2013 05:09:05 +0000

Like GNOME 3?

Bad NIH, good NIH

dlang — Thu, 14 Mar 2013 03:10:39 +0000

you are so focused on what is the 'norm' today that you are completely blind to the future.

remote display uses that are going to become very common in the near future (especially when connected to mobile devices that do not have the CPU power to render locally, then ship VNC style full-frame images out to the remote display)

1. Google Glasses style head mounted displays.

Google is far from the only company working on this sort of thing. Many of these uses are text or simple geometric objects overlayed on the live video, shipping the video to the phone, doing the overlay, and shipping the result back out is wasting a lot of bandwidth, and battery. Not Going To Happen (at least not for very long). What's going to happen is the video will get shipped to the phone (although not necessarily in full resolution), the phone will craft the overlay, and the overlay will be transmitted back to the headpiece to be combined there with the direct feed from the camera.

2. remote displays (frequently wireless) from mobile devices to large, high-res displays.

Haven't you seen any of the many TV shows or movies recently that show people pulling something up on a phone/tablet and then 'flicking' the window over to the full display? What makes you so sure that this is not going to happen?

There are probably a lot of other examples that people could point out, but just because you don't currently use remote displays doesn't mean that they aren't going to be very popular very soon.

Bad NIH, good NIH

nix — Wed, 13 Mar 2013 23:43:38 +0000

It doesn't work better than X over even low-latency links the moment you have to scroll. Scrolling a windowful of text using normal VNC is laggy even over a quiet gigabit ethernet link: over anything slower it is hopeless.

Bad NIH, good NIH

HelloWorld — Wed, 13 Mar 2013 22:51:38 +0000

Of course it's suboptimal. It's also easy to implement and doesn't need application or toolkit changes and still works better than X (which is unusable over high-latency links). Again, the question isn't whether it's possible to do better but whether someone can be bothered to invest a significant amount of work in a better solution. Given that remote applications == web applications for 95% of all users, I don't think anybody will.

Bad NIH, good NIH

nix — Wed, 13 Mar 2013 21:46:34 +0000

So... your 'argument' is that VNC-like stuff is 'good enough', even though it is clearly much worse than glyph-by-glyph stuff for the vast majority of windows that anyone ever opens using any windowing system -- those windows filled with text? (Discounting, for these purposes, games and video playback, which clearly should be local or use a video compression algorithm of some sort.)

Almost every use case (save only the GIMP, Inkscape and their ilk) can be covered by video compression or glyph-by-glyph stuff. VNC is bad for *both* of these. As far as I can tell, VNC is far suboptimal for *everything*.