Announcement

Collapse
No announcement yet.

The Story of Ubuntu's Mir Abstraction Layer (MirAL)

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

  • #31
    Originally posted by Sesivany View Post
    Wayland has been on phones since 2013 and then on TVs and other gadgets without major problems. It's the desktop with all the legacy apps, lots of input devices, multiple screens, a lot of required functionality etc. where the stuff gets really hard.
    I never claimed otherwise. You missed my point - Ubuntu Touch has been running on Android GPU HALs*, as well as on native stacks. Wayland requires a native wayland EGL stack.

    * And that has been a major advantage to Ubuntu Touch, even as a grass-root alternative OS on Android mobile devices.

    Comment


    • #32
      Originally posted by bregma View Post

      So, you've run Firefox on XWayland. X11. Not native Wayland. Most desktop systems using a Wayland compositor also run a single session-wide X11 server, providing all the security holes and disadvantages of X11 right out of the box. Screen scraping, key grabbing, snooping and surveillance, it's all there.
      Well, you seem to have missed that there's an experimental native Wayland version of Firefox. Native, NOT XWayland.
      http://www.phoronix.com/scan.php?pag...yland-Via-Copr

      In fact, it even says that you don't need to be running an X Server at all.
      "with native Firefox GTK3 on Wayland without resorting to XWayland."

      If you still think you need XWayland for that experimental build, then please explain to me why the article (and dev of the build) says you don't.
      Last edited by Vistaus; 04 April 2017, 06:52 AM.

      Comment


      • #33
        Originally posted by bregma View Post

        So, you've run Firefox on XWayland. X11. Not native Wayland. Most desktop systems using a Wayland compositor also run a single session-wide X11 server, providing all the security holes and disadvantages of X11 right out of the box. Screen scraping, key grabbing, snooping and surveillance, it's all there.
        I've run Firefox on Wayland NATIVELY, believe me, I know what I'm talking about ;-)

        Comment


        • #34
          Originally posted by Vistaus View Post

          Well, you seem to have missed that there's an experimental native Wayland version of Firefox. Native, NOT XWayland.
          http://www.phoronix.com/scan.php?pag...yland-Via-Copr
          That repo is no longer updated. The newest builds are available in the Firefox Flatpak repo: https://firefox-flatpak.mojefedora.cz/

          Comment


          • #35
            Originally posted by darkblu View Post
            You seem to start with taking your assumptions as ground truth. In reality, Unity8/Mir has been a viable platform for more than a year on Ubuntu Touch, running on top of Android EGL stacks. So Mir has been a major enablement component to Ubuntu Touch. Just giving you an example here (I'm fully Wayland/Mir-neutral).
            Wayland enabled it before that, for Sailfish. So it's not like Ubuntu touch didn't have a working use case to learn from. They literally had no need to reinvent the wheel.

            Originally posted by darkblu View Post
            I never claimed otherwise. You missed my point - Ubuntu Touch has been running on Android GPU HALs*, as well as on native stacks. Wayland requires a native wayland EGL stack.

            * And that has been a major advantage to Ubuntu Touch, even as a grass-root alternative OS on Android mobile devices.
            Incorrect. Ubuntu Touch used (without even crediting first), all the work that went into libhybris, which enabled Wayland based systems to run on Android HAL before Ubuntu Touch. That was really not nice of Canonical.

            That's how libhybris developer described it:

            Earlier this year however, I discovered that a well-known company had taken the code - disappeared underground with it for several months, improved upon it, utilized the capability in their advertisements and demos and in the end posted the code utilizing their own source control system, detached from any state of that of the upstream project's. Even to the extent some posters around the web thought libhybris was done by that company itself.
            See

            * https://mer-project.blogspot.com/201...u-drivers.html
            * https://mer-project.blogspot.com/201...u-drivers.html
            Last edited by shmerl; 04 April 2017, 11:51 AM.

            Comment


            • #36
              Originally posted by Sesivany View Post

              I run Firefox on Wayland natively although it's still experimental. BTW Mir backend in GTK+ doesn't help that much here because Firefox uses it only for a subset of functionality. It does a lot of stuff directly with X11 and newly with Wayland, so supporting Mir will be a non-trivial amount of work on the Firefox side.
              Exactly. And it would be a major drain on developers.

              Comment


              • #37
                I knew I needed to make more popcorn before reading this thread...

                Just let them do what they want to and let the results speak for themselves.

                Comment


                • #38
                  Originally posted by Scias View Post
                  Just let them do what they want to and let the results speak for themselves.
                  They are already doing what they want. It doesn't mean they can't be criticized, when what they are doing is actually damaging Linux desktop as a whole.

                  Comment


                  • #39
                    Originally posted by bregma View Post
                    (1) There is really no advantage to using the Wayland wire protocol with Mir display server stack. Mir already has a wire protocol. It's probably possible to use a subset of the Wayland wire protocol, and add some extensions, but then you would have a non-standard, incompatible version of the protocol that would take another year to deliver for what net benefit at what net cost?
                    The advantage would be that it would be compatible with applications, toolkits, and drivers written for Wayland rather than having to maintain two of each.

                    Originally posted by bregma View Post
                    (2) Wayland is not a compositor. Wayland is a wire protocol. You could not turn Mir into a Wayland compositor, because Wayland is not a compoitor.
                    What? A "Wayland compositor" is a compositor for Wayland, not Wayland itself. So kwin is a Wayland compositor, Mutter is a Wayland compositor, Weston is a Wayland compositor, etc.

                    Originally posted by bregma View Post
                    I'd like to turn this line of reasoning around, and ask this. If Elementary, KDE/Plasma, GTK3/Gnome, Weston, etc. all different compositing display servers not invented here but not a waste of time, why is Mir considered a waste of time?
                    Because they are all using the same protocol and interface with applications, toolkits, and drivers using the same API/ABI. An application written for Wayland will work with any Wayland compositor. That is the whole point of using a single protocol and API/ABI.

                    This is not the case with Mir, stuff written for Mir is not compatible with Wayland. Toolkits have to maintain separate Mir and Wayland implementations. Applications that need access to the display server require separate Mir and Wayland implementations.

                    Comment


                    • #40
                      Originally posted by bregma View Post
                      No, Wayland is not and has never been an API for a window managers to talk to a compositing display server. Wayland is a wire protocol for communication between a client program and a compensating display server that contains a window manager. They are in fact opposites.
                      That is simply false. Wayland is a wire protocol and an API (or, rather a server API and a client API). Applications can choose to either talk to the compositor through the wire protocol or through the client API. Compositors likewise can either use the wire protocol or the server API. In Wayland, both the protocol and APIs are stable and backwards-compatible.

                      Mir is also a wire protocol and a client API. The difference is that in Mir, only the client API is considered stable while the protocol is an internal implementation detail subject to breaking changes at any time.

                      Comment

                      Working...
                      X