I also reach the opposite conclusion from you regarding having people familiar with Xorg. Xorg devs are familiar with Xorg, they know what its flaws are, they know what is limitations are, and they know what developers today need. Mir developers, on the other hand, know next to nothing about display servers. They don't know what a display server really needs, and they don't know what problems people have run into the past when implementing them so they don't know what they should avoid doing (as their security bugs demonstrate).
Last edited by TheBlackCat; 06-11-2014 at 01:00 PM.
Is there some particular test automation software that you are concerned does not run under Ubuntu, but works under other Linux distributions?
You can accept that someone else has a different opinion, but that doesn't mean you should discuss with such someone.
And like it was already said, being done by former/current X developers is a strenght. You can already see how input is *insanely* more secure in Wayland than it is in X.
In the other side, Mir repeats one of Xorg biggest flaws : server-side allocated buffers. Even X with DRI2 and now DRI3/Present try to completely get rid of that actually.
GNOME 3.12 is almost fully usable on Wayland right now with full XWayland transparency for X apps. "KDE 5", E19, Hawaii and many others shells and apps like chromium, xbmc and SDL are already in working state or planning to support Wayland.and what is worse, wayland is still not used by most projects anyway
The same cannot be said about Mir, no one besides Canonical supports it and no native Mir app besides Unity 8 (which is still to be seen on a Desktop flavour) and ports from Wayland ports made by Canonical mostly (chrome and SDL for example).
All upstream opensource drivers support (X)Wayland out of the box, while Mir still requires downstream patches yet. NVIDIA is actually on the way to support XWayland on their proprietary driver (see Xorg mailing list) while Mark promises Mir support since the beggining yet not even a sign from upstream.
There's already at least 2 fully working commercially selling phones using Wayland (Jolla and Samsung Z), none using Ubuntu Touch yet (wasn't one of the reasons of Mir to hit the market before Wayland could be ready ?)
So no, I don't know on which planet you live, but Mir is far from being the most supported or used solution now, despite Ubuntu being the most popular distro. Heck, even Ubuntu flavours don't want it.
Nonsense. Both have APIs and protocols, except Mir's protocol is private and not meant to be stable.then Mir is xorg done right. I agree with Mark's notion of an API driven driver, rather than a collection of implemented protocols. In both cases implementations can vary but at least they can be externalized. One only has to look at the popularity of direct X and direct 3D APIs- if its design was anything like X or wayland, it is unlikely to have become popular. Apple's platform benefited from coco and openGL.
Direct3D is a rendering API, and has absolutely nothing to do with display servers or compositors.
Except that the quadrillion of already available window manager don't require specific drivers, and toolkits/apps don't need to be modified to work with specific WMs because we only had X. This is not the case in the Mir case, which needs specific EGL extensions and toolkit support.We ALREADY have a fragmented "display server" platform, without Mir.
Again nonsense. Both Wayland and Mir just need an EGL driver. There's no DDX driver involved like in the Xorg case, so drivers shouldn't need to be modified for each new version.I think that with an API driven approach that Mir is taking, the driver support will be better, as has been with windows (direct 3D, draw, X etc). Besides, it is unlikely to be affected by kernel upgrades or as is the case now, with (xorg) library changes.
If Wayland was vaporware then the major DEs and toolkits wouldn't run flawlessly on it already, nor would it power phones and embedded systems, while Mir after so many unfulfilled promises and delays has only shown flipping fullscreen surfaces so far, which is the very least a display server can do.Wayland in the end will create more segmentation, since wayland is vaporware people using it have 2 choices, use Weston which can be said to be a tech preview or implement the whole Wayland protocol. You could see this happened on the Raspberry Pi, the collabora guys wrote the whole wayland implementation to leverage the hardware. And again you see most projects writing their own compositors and implementations, I would prefer an approach similar to that of the linux kernel, where every platform code is stored on the same repo so all you need is some configure flags to compile for a specific platform, but wayland in the other hand will be all over the place, pieces here and there.
And while this is true that Compositors might end with different rendering backends (KMS, fbdev, rpi...) and different implementations of them, there's nothing that prevents standardization or abstraction layers. It's already happenning with libinput and xdg_shell. But apps and toolkits should run regardless or the compositor, that's the point of the protocol.