Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: Mark Reiterates Mir Will Have First-Class Driver Support

  1. #11
    Join Date
    Feb 2011
    Posts
    1,161

    Default

    Quote Originally Posted by chrisb View Post
    This is not really an issue. The reality is that developers who are targeting Ubuntu already need an Ubuntu build and test environment, certainly if they are doing professional development this will be the case. Sure, there might be some developers who have personal objections/hate Ubuntu, and refuse to install it, but could you imagine telling your boss (or client):

    [...]

    It would not be professional. On the other hand, hobbyist developers can choose to support whatever platform they want. They are free to choose not to support a particular platform, and accept the consequence that their product will not perform as well, or be as popular, on that platform.
    That is great...if your testing system is built on Ubuntu. But how many automated testing systems are built on Ubuntu?

  2. #12
    Join Date
    Dec 2013
    Posts
    84

    Default

    Quote Originally Posted by mvaar View Post
    the 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.
    All's i have to say to a shit bag like you..


  3. #13
    Join Date
    Feb 2011
    Posts
    1,161

    Default

    Quote Originally Posted by mvaar View Post
    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.
    So what, specifically, are the advantages of Mir over Wayland? (besides the imaginary one of Wayland not providing the API it actually does provide)

    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).

    Quote Originally Posted by mvaar View Post
    I agree with Mark's notion of an API driven driver, rather than a collection of implemented protocols.
    Wayland 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.
    Last edited by TheBlackCat; 06-11-2014 at 12:00 PM.

  4. #14
    Join Date
    Feb 2013
    Posts
    441

    Default

    Quote Originally Posted by TheBlackCat View Post
    That is great...if your testing system is built on Ubuntu. But how many automated testing systems are built on Ubuntu?
    Developers targeting Ubuntu, and who are using automated tests as part of their development process, will have their tests running in Ubuntu. If they also target other platforms with automated tests, then they will also test under those environments. There wouldn't be much point in targeting a platform with test code, if you could not run the test code on that platform.

    Is there some particular test automation software that you are concerned does not run under Ubuntu, but works under other Linux distributions?

  5. #15
    Join Date
    Apr 2014
    Posts
    18

    Default

    Quote Originally Posted by Attentäter View Post
    All's i have to say to a shit bag like you..

    Actually 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.

  6. #16
    Join Date
    Mar 2013
    Posts
    171

    Default

    Quote Originally Posted by TheBlackCat View Post
    Wayland 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.
    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.

  7. #17
    Join Date
    Sep 2012
    Posts
    687

    Default

    Quote Originally Posted by Cerberus View Post
    Actually 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.
    To his defense, mvaar's opinion is quite incredibly ill-informed (such misunderstanding of wayland and mir would have been acceptable last march, but today it looks a bit like bad faith).
    You can accept that someone else has a different opinion, but that doesn't mean you should discuss with such someone.

  8. #18
    Join Date
    Sep 2012
    Posts
    687

    Default

    Quote Originally Posted by TheOne View Post
    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.
    Well, the point was that the raspberry Pi backend stuff was not applicable to other devices. What would you suggest instead?

  9. #19
    Join Date
    Nov 2010
    Location
    California
    Posts
    318

    Default

    Quote Originally Posted by Cerberus View Post
    Actually 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.
    sometimes having a "different" opinion for the sake of being different, is called hubris...

  10. #20
    Join Date
    Oct 2007
    Posts
    34

    Default

    Quote Originally Posted by mvaar View Post
    because the same people are doing both and are making the same mistakes ALREADY
    [citation needed]

    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
    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.
    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.
    Nonsense. Both have APIs and protocols, except Mir's protocol is private and not meant to be stable.
    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.
    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.

    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.
    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.

    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.
    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.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •