Page 2 of 9 FirstFirst 1234 ... LastLast
Results 11 to 20 of 86

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

  1. #11
    Join Date
    Jul 2012
    Posts
    762

    Default

    Quote Originally Posted by Anarchy View Post
    Sadly, only Martin has the right to complain because in the end he will have to deal with the two display servers.
    Martin will never have to deal with Mir, since KDE won't work on it.

  2. #12
    Join Date
    Jun 2009
    Posts
    1,137

    Default

    well another point (swiftly mentioned by martin) is not all apps use big toolkit like Gtk/Qt5/EFL, for example VLC/Mplayer-Mpv/Blender/wxGtk based apps/etc, and in fact many of this applications have to deal directly with display servers regardless the tollkit(for example, mpv have to directly query the display system regardless any toolkit).

    another structural problem is composition, in wayland as shown in many demos provide a very flexible composition path and since the composition can be done by the client and/or the compositor at global scope allows you to deal with pretty freaky neat possibility like nested compositing per client, for example i could write a plugin for MPV player that allows to composite the vdpau overlay with client side effects and add multilayer presentation for subs/PIP/Geodata and inform the global compositor that only the main overlay is used to plasma preview task widget(ofc kwin/mutter/efl should support this through dbus and/or as an compostior plugin) but Mir do server side central process composition and even if it can be disable per process i will have to relay in EGL for do in process flatten superpositioning since i do not know if Mir even support nested composition or if it works as expected, so as a developer ill have to choose either take the safe path that should theoretichally work in all 2 at the cost of effciency and a neat feature or support only wayland?


    sure you can argue that mir will probably allow something similar, bla bla but at the end of the day is a 3rd path i have to test, a 3rd api i have to learn, a 3rd system i have to QA, probably a third code path i have to write, a 3rd source of problems(sure lets assume mir support this but there is no warranty will always work with all systems, especially since it could not be too popular for ubuntu specific apps), is a 3rd path i have to test against a miriad of drivers, etc. <-- this is the problem

    Note: ofc in the example Xorg will automatically hide all this feature since is not technically feasible at all but as a developer i knew this and decided to add legacy fallback for X or Y reason

  3. #13
    Join Date
    Jan 2012
    Posts
    86

    Default

    Quote Originally Posted by blackout23 View Post
    Martin will never have to deal with Mir, since KDE won't work on it.
    Ask him in a couple of years.

  4. #14
    Join Date
    Nov 2010
    Posts
    396

    Default

    "This is not for political reasons as itís so often claimed, but for technical, because I cannot test the patches (Mir not available on Debian) and our CI system cannot build it."
    So if canonical makes it available in debian he will test things are he will come up with another "convenient" excuse ?

  5. #15
    Join Date
    Jun 2009
    Posts
    1,137

    Default

    Quote Originally Posted by madjr View Post
    So if canonical makes it available in debian he will test things are he will come up with another "convenient" excuse ?
    well first you will need

    1.) Digia offer upstream support for Mir, for now is downstream only (whine to them )
    2.) Mir specific driver code make it upstream (doesnt look good especially since amd and intel are not specially peachy about custom driver internals for Mir only)
    3.) pass debian technical board (won't pass only all of the above are well supported)

    then martin have to decide if he want the extra burden(which i suppose you won't help, after all ubutroll only ability so far is whine and cry rivers of tears) and then someone will have to actually step up and provide upstream support from canonical, so at best he has 2 solid years to be Mir worry free.

    won't hurt if all the ubutroll here take those 2 years to actually learn some engineering to actually help their cause instead of posting to the world that you don't have idea what you are talking about and whine in a technical forum where no one take you seriously at all or care about your baseless conspiration theory.

    since most hurted troll will go all grammar nazi, im not american and i don't care

  6. #16
    Join Date
    Jan 2014
    Posts
    62

    Default

    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.

    I don't see the KDE project doing anything near what Ubuntu as a whole is achieving, for the good of all of us who support free software. Perhaps it's indeed the Ubuntu project that will decide to abandon Mir and join the "industry standard." But, perhaps it's KDE that will learn that it's best to hop on Ubuntu's platform if they want to remain relevant.

    Time will tell. In the meantime, the Mir project is not doing anything to stop the Wayland project from moving forward. If anything, there are a lot of efforts that converge, and both teams will benefit when the other progresses. So, can we stop these complaints and do our best?

    On that note, it would be nice if Canonical folk would stop making these degrading comments. It seems that every time they have something to say publicly, it ends up offending someone in the community. Avoid PR, Canonical: you're really bad at it. Just keep plugging away at Mir and make sure it's great. A lot depends on it living up to your expectations for it.

  7. #17
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by jrch2k8 View Post
    3.) pass debian technical board (won't pass only all of the above are well supported)
    Why the hell would the CTTE have to decide about availability of Mir in the Debian Repos? No one is talking of making it default here.

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

  8. #18
    Join Date
    Sep 2011
    Posts
    28

    Default

    Why are they spending hundreds of thousands of dollars (possibly more) on Mir if "it doesn't matter" to the end user? They don't have support from the hardware vendors, the Mesa community, GNOME or KDE... who wants this? Why?

  9. #19
    Join Date
    Jul 2013
    Posts
    68

    Default

    Why is Canonical constantly publicly humiliating them selves? Oh! I remember! Canonical have no other objective than to divide and rule...

  10. #20
    Join Date
    Jan 2009
    Posts
    1,406

    Default

    Quote Originally Posted by HeavensRevenge View Post
    Yes the display server DOES matter, this is just them trying to "brush off" something huge as something small... trying to sweep it under the carpet and hide the fact they created a mess yet again.

    In Mir every window is it's own completely separate compositor making it an orchestration of compositors to create a final display output vs compositing to one surface like normal, Which is why it's architecture is a freaking interconnected mess probably worse than X itself.
    is the image straight from Cononical's source repo in a png format from http://www.reddit.com/r/LinuxActionS..._architecture/ a post I had my buddy to create for me since I'm no reddit addict, decide for yourself...

    PS Sorry for such a huge image, I dont know how to use a smaller version...
    This is interesting. Thanks for the post.

Posting Permissions

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