Originally posted by chrisb
View Post
Announcement
Collapse
No announcement yet.
Mark Reiterates Mir Will Have First-Class Driver Support
Collapse
X
-
Originally posted by mvaar View Postthe re-inventing, I mean. You picked mir but the OSS world is full of half-baked, replicated solutions and apps. Even the desktops- who needs so many ? I am sure the lame answer is choice, except when the choice is offered by someone that threatens my house of cards.
If wayland is considered an improvement over xorg ( and I strongly disagree with it, primarily because the same people are doing both and are making the same mistakes ALREADY and what is worse, wayland is still not used by most projects anyway), 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.
Comment
-
Originally posted by mvaar View PostIf wayland is considered an improvement over xorg ( and I strongly disagree with it, primarily because the same people are doing both and are making the same mistakes ALREADY and what is worse, wayland is still not used by most projects anyway), then Mir is xorg done right.
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).
Originally posted by mvaar View PostI agree with Mark's notion of an API driven driver, rather than a collection of implemented protocols.Last edited by TheBlackCat; 11 June 2014, 12:00 PM.
Comment
-
Originally posted by TheBlackCat View PostThat is great...if your testing system is built on Ubuntu. But how many automated testing systems are built on Ubuntu?
Is there some particular test automation software that you are concerned does not run under Ubuntu, but works under other Linux distributions?
Comment
-
-
Originally posted by TheBlackCat View PostWayland provides an API. You just aren't forced to use it. And being forced to use it is a huge restriction. For example, developers making compositors/window managers need lower-level access. Mir only solves that problem by not letting anyone else write compositors/window managers. That doesn't sound like an advantage to me.
Comment
-
Originally posted by Cerberus View PostActually you proved his point with this, you showed how that open source and open minded community can be petty and have difficulties accepting the fact that someone else has a different opinion.
You can accept that someone else has a different opinion, but that doesn't mean you should discuss with such someone.
Comment
-
Originally posted by TheOne View PostWayland 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.
Comment
-
Originally posted by Cerberus View PostActually you proved his point with this, you showed how that open source and open minded community can be petty and have difficulties accepting the fact that someone else has a different opinion.
Comment
-
Originally posted by mvaar View Postbecause the same people are doing both and are making the same mistakes ALREADY
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.
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.
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.
We ALREADY have a fragmented "display server" platform, without Mir.
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.
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.
Comment
Comment