Does The Display Server Matter? The Latest Mir vs. Wayland Argument

[Gusar]

In this case, restricting the definition of "the community" to those who made the decisions on dbus and systemd.

I didn't restrict anything. I gave those two as *examples* that I immediately thought of. They are more than sufficient to refute your point. There was consensus, in more cases than just the examples I gave, in contradiction to your claim that there never is any.

[toka]

This was already answered, but it's actually the main issue with Mir. Everyone would have been happy if they made Mir a Wayland client (or whatever is the right term for it) instead of a display server.

Display server = the running software (not a library) that manages input and output for all its clients
Wayland compositor = a type of display server => KWin is at the moment a compositing window manager, there will be a KWin that is a Wayland compositor
Mir = display server, that should support the display server protocols: mir, X, wayland, maybe Android's SurfaceFlinger, etc

[jrch2k8]

Display server = the running software (not a library) that manages input and output for all its clients
Wayland compositor = a type of display server => KWin is at the moment a compositing window manager, there will be a KWin that is a Wayland compositor
Mir = display server, that should support the display server protocols: mir, X, wayland, maybe Android's SurfaceFlinger, etc

almost right(unless last week something changed in their repos), Mir is a server and compositor process that speak Mir protocol and can reuse android driver through libhubris as wayland do, a canonical developer posted that is theoretically possible to make Mir compatible"ish" with wayland in the future. X compatibility is done through an layer called XMir somewhat similar to old XWayland patches but so far this layer is not rootless(aka need a whole display for a base full screen texture like Xorg today) unlike XWayland that already is rootless(aka each app render it unique texturing to an appropiate size Wayland surface)

all else seems right

[toka]

https://en.wikipedia.org/wiki/File:The_Linux_Graphics_Stack_and_glamor.svg

Does anybody want to share some insights about SurfaceFlinger? Is this the Android "display server"/"display server protocol"? Does Android even have such a thing, since there is no room on the screen anyway, so every app has to run fullscreen, so the "display server" could be something very simple. What about Mac OS X? What display server protocol does it use?

[V10lator]

Yes, it means extra work for various developers. But the decision has been already been made, and Canonical is already going full-steam ahead. Instead of complaining, it's a good time to get working on Mir support, so that your shells and apps and other gizmos will be enjoyable on the upcoming onslaught of mobile and touch Ubuntu devices.

Why shuld I care about ubuntu mobile when I can't even buy such a product right now? On the other hand when I target Wayland I'm also targeting Tizen and SailfishOS. Both of them are mobile OSes and one of them is even on the market right now. In other words: When I look at the current market I would say: Ignore Mir, go Wayland!

But, perhaps it's KDE that will learn that it's best to hop on Ubuntu's platform if they want to remain relevant.

Good joke. Tell me one product that I can buy right now that uses Mir. I bet I can give you more examples of products on the market that use Wayland.

In the meantime, the Mir project is not doing anything to stop the Wayland project from moving forward.

Except that developers that want to target both but don't want to support two display servers will target X11 (cause of XWayland and Xmir). Stopping projects from moving to Wayland is not "stop the Wayland project from moving forward"?

On that note, it would be nice if Canonical folk would stop making these degrading comments.

That's where we finally agree. Even if I would take a step more: Canonicals PR is nothing more than sprading FUD.

as long as KDE supports the so called "industry standard" (read: what Red Hat does) they are on the safe side.

If you mean Wayland with "industry standard" then, well, companies behind it are Hed Hat, Intel, Samsung, IBM, Mercedes benz, BMW and so on (sometimes it feels like the list is endless...) on the other side companies behind Mir is, well, Canonical... So yes, Wayland is "industy standard".

Mir would/will support a multitude of protocols.
Correct or not?

Not correct. But I'm to lazy to write down why, just this: If Mir would/will support the Wayland protocol we wouldn't even have this talk. However I'm sure you'll get a detailed reply from somebody other.

Mir is a server and compositor process that speak Mir protocol

And that's it: Mir is the only one speaking the Mir "protocol". Even if somebody other would want to speak it it wouldn't work in the long run as the "protocol" isn't stable. In other words: There is no protocol, it's just some APIs the Mir server and the Mir compositor speak to each other. But these APIs will never be stable nor are they meaned to be talked by anything other.

[jrch2k8]

https://en.wikipedia.org/wiki/File:T...and_glamor.svg


Does anybody want to share some insights about SurfaceFlinger? Is this the Android "display server"/"display server protocol"? Does Android even have such a thing, since there is no room on the screen anyway, so every app has to run fullscreen, so the "display server" could be something very simple. What about Mac OS X? What display server protocol does it use?

surface flinger is something like Mir but android specific that offer the barely needed functionality for android GUI(like an android GUI specifically tailored strip down X/Mir that uses EGL)

Mac OS X quartz is like the father of Wayland/Mir, the first true frame perfect rootless graphic server and well is very established this days, drivers aren't that great tho but technically is more like Mir"ish" that instead of EGL uses AGL(as Apple GL for context handling), protocol is Quartz XD

[jrch2k8]

to complete the idea here, in resume(and in this order) Quartz, Surface Flinger and Mir work kinda similar and were conceived as the easy cheap way out of X11, aka trimm lots of fat from X, remove GLX elephant and switch to a more lean context handler like EGL/AGL and then finally add some simple but functional compositor integrated into the server to handle the eye candy, shadows, etc.

the basic concept of wayland is way more radical, basically behaves like a language like OpenCL or OpenGL or Mantle but to speak GUI(instead of 3D) needs directly into the GPU without middle mans, aka you use wayland language to create your own unique compositor and or server and/or client that you can transform in any way you feel like it using any supported GPU draw language(like opengl/es or GPU specific ASM or even c/c++ if hardware accel is not available), so the capabilities of wayland are incredibly flexible only limited to hardware limitations and since is basically operates as close to the hardware as is possible without reach ASM, the performance is impressive as long as the render code is efficient but wayland itself is basically hit free to the hardware.(very diluted to make it more easy to digest)

wayland in this case is way harder and expensier to develop that other counterparts but the capabilities will pay in the long run(in short term won't be as fantastic because first devs need to match what you are used to today) but for example in wayland(which is not possible with any other today techs) can improve games by releasing the desktop compositor(kwin/mutter/etc) and let the game itself composite and parallelize its own render pipe in the GPU's/operations is consider best and swap to screen when its considered right for the game engine, etc.(specialized nested compositing) and then just send control back to desktop optimized compositor(kwin/mutter/etc) when exited or switched back.

and well another nasty miriad of possible scenarios/optimizations with wayland that wont have time to explain them all

[Delgarde]

granny speaking here: is the "display server" = mir the problem? or is the "display server protocol"=libmir-client + libmir-server?

A dispute with less fanboys: http://lwn.net/Articles/541336/

The problem is that from top to bottom, Mir is a completely independent stack, incompatible with what the non-Canonical community is doing with Wayland. And that makes for extra burden on developers, having yet another stack to support, one which is relevant only to Ubuntu users.

It's not a technical problem, in that one is superior to the other - it's simply that the existence of Mir forces a split between "Canonical" and "everyone but Canonical"... developers don't want to support both, so we end up with this unfortunate battle for supremacy...

[daniels]

Does anybody want to share some insights about SurfaceFlinger? Is this the Android "display server"/"display server protocol"? Does Android even have such a thing, since there is no room on the screen anyway, so every app has to run fullscreen, so the "display server" could be something very simple. What about Mac OS X? What display server protocol does it use?

SurfaceFlinger is comparable to Wayland (protocol and compositor), Mir or X11. It supports composition of multiple windows, zerocopy buffer handling, etc. Its handling is perhaps a little primitive compared to Wayland, but that's to be expected of something designed a few years ago.

Getting into more detail, SurfaceFlinger is the compositor (e.g. Weston, Mutter), whilst the protocol is comprised of a few components including GraphicBuffer/gralloc, Surface, etc.

[Luke_Wolf]

Except that developers that want to target both but don't want to support two display servers will target X11 (cause of XWayland and Xmir). Stopping projects from moving to Wayland is not "stop the Wayland project from moving forward"?

Those I hope you realize are going to be the vast minority of applications, that #1 care about the display server to begin with, and #2 want to target both wayland and mir, and #3. aren't willing to maintain for two display servers.

KDE, GNOME, and Enlightenment (and I believe LXDE-Qt) are all explicitly moving to support Wayland, SDL2 already supports both, Red Hat and SUSE are onboard with wayland which means that their tools will support Wayland, and they will ensure that LibreOffice, Firefox and all the enterprise applications support Wayland, Chromium already runs under wayland, Proprietary games are going to use whatever SteamOS goes with. Whatever is left if said developers you propose existing actually exist are going to be a small number of very niche applications that aren't really holding back the progress of wayland, because all of the applications that most people actually care about are or have a force backing them that ensures that they will be ported to wayland.