Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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.

    Comment


    • #12
      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

      Comment


      • #13
        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.

        Comment


        • #14
          "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 ?

          Comment


          • #15
            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

            Comment


            • #16
              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.

              Comment


              • #17
                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.

                Comment


                • #18
                  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?

                  Comment


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

                    Comment


                    • #20
                      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.

                      Comment

                      Working...
                      X