Announcement

Collapse
No announcement yet.

Mir 0.31 Is On The Way With MirAL 2.0, Wayland XDG-Shell Support

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

  • Mir 0.31 Is On The Way With MirAL 2.0, Wayland XDG-Shell Support

    Phoronix: Mir 0.31 Is On The Way With MirAL 2.0, Wayland XDG-Shell Support

    Ahead of Ubuntu 18.04 LTS next month the Mir developers are working to release Mir version 0.31...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    ELI5 -- Technical Achievements and bullshit aside, what practical scenarios and situations would I want to use Mir in as opposed to other options.

    Comment


    • #3
      Originally posted by ElectricPrism View Post
      ELI5 -- Technical Achievements and bullshit aside, what practical scenarios and situations would I want to use Mir in as opposed to other options.
      A repurposed Mir (that could act as a Wayland compliant compositor on various distributions) may be helpful to smaller DE development groups that may lack the resources to develop their own Wayland complaint compositors. For example, as reported on Phoronix, Martin Wimpress (from MATE) has stated:

      The rumors of Mir's death are greatly exaggerated. MATE is a very small team, with extremely constrained time. Implementing Wayland directly is, at our current development velocity, several years away IMO. If Mir could provide us a fast path to supporting Wayland we (and possibly other desktops without Wayland support) should explore it....Using Mir as the Wayland compositor, while still a chunk of work, is considerably less work.
      So, you may ask, why not just use Mutter or KWin?

      Given MATE's use of GTK, some think that MATE could use Mutter as a drop-in Wayland compositor. But according to Ikey Doherty lead developer of Solus and Budgie) in this thread:

      At the most fundamental level Mutter does not expose support for panel positioning or strut reservation on Wayland, nor arbitrary window placement for blessed windows, which is everything that mate-panel would actually *need* to be useful.
      Of course, KWin may be more flexible than Mutter.

      And actually, Budgie 11 (the future release of Budgie that will have Wayland support) is being developed with KWin. But whether Budgie 11 ultimately relies on KWin (or something else) for Wayland support remains to be seen.

      Also, and not to knock KWin, but KWin was originally written for X11 and has been heavily modified to allow it to act as a Wayland-compliant compositor. In comparison, although Mir wasn't initially written to comply with the Wayland protocol, Mir was written from the ground up to achieve goals that are consistent with the goals of the Wayland protocol. So adapting the Mir display server to be Wayland compliant may be more straightforward than what's been required, thus far, to adapt KWin and Mutter to be Wayland-compliant compositors.

      Hopefully, when finished, Mir will offer a generalized solution that will be easier for DE devs to apply.

      Comment


      • #4
        Lemme check if I understand recent developments.
        • AMDGPU is a modern GPU driver that entered mainline thanks to DC code, formerly DAL ("Display Abstraction Layer").
        • Vulkan is a low level graphics API. We could consider it a "minimal abstraction layer over the GPU driver". If we had a modern AMD GPU (everyone in the FOSS community would like to have one), that would be a minimal abstraction layer over a GPU driver that contains an abstraction layer.
        • Wayland is only a specification, so any Wayland compositor is an abstraction layer by design, including Mir.
        • As of Vulkan 1.1, we could have a Wayland compositor over Vulkan, which translates to an abstraction layer over another abstraction layer over DC/DAL (abstraction layer).
        • MirAL is an abstraction layer over Mir. That could potentially translate to an abstraction layer (MirAL) over another abstraction layer (Mir/Wayland) over yet another abstraction layer (Vulkan) over DC/DAL (abstraction layer).

        That's a whopping 4 layers of abstraction, delivering the best GPU user experience ever to the FOSS community at large. And I like it. But... weren't abstraction layers supposed to be bad?

        p.s. and I haven't taken various other "this over that" APIs into account, e.g. glo, wine, dxvk, kvm, vk9, wine over dxvk over vk9 over kvm and the like...
        Last edited by lucrus; 17 March 2018, 05:10 AM.

        Comment


        • #5
          Originally posted by GizmoChicken View Post

          A repurposed Mir (that could act as a Wayland compliant compositor on various distributions) may be helpful to smaller DE development groups that may lack the resources to develop their own Wayland complaint compositors. For example, as reported on Phoronix, Martin Wimpress (from MATE) has stated:



          So, you may ask, why not just use Mutter or KWin?

          Given MATE's use of GTK, some think that MATE could use Mutter as a drop-in Wayland compositor. But according to Ikey Doherty lead developer of Solus and Budgie) in this thread:



          Of course, KWin may be more flexible than Mutter.

          And actually, Budgie 11 (the future release of Budgie that will have Wayland support) is being developed with KWin. But whether Budgie 11 ultimately relies on KWin (or something else) for Wayland support remains to be seen.

          Also, and not to knock KWin, but KWin was originally written for X11 and has been heavily modified to allow it to act as a Wayland-compliant compositor. In comparison, although Mir wasn't initially written to comply with the Wayland protocol, Mir was written from the ground up to achieve goals that are consistent with the goals of the Wayland protocol. So adapting the Mir display server to be Wayland compliant may be more straightforward than what's been required, thus far, to adapt KWin and Mutter to be Wayland-compliant compositors.

          Hopefully, when finished, Mir will offer a generalized solution that will be easier for DE devs to apply.
          Since you explained to great detail why MATE wouldn't be able to use Mutter and probably not KWin, tell me why exactly they can't use Enlightenment's window manager (as a base)? 'Cause, you know, Enlightenment has great Wayland support as well. Not sure if you were aware of that 'cause you only seem to know Mutter, KWin and Mir... but if you were aware, could you explain why MATE can't use Enlightenment's window manager as a drop-in replacement?

          Comment


          • #6
            Originally posted by Vistaus View Post

            Since you explained to great detail why MATE wouldn't be able to use Mutter and probably not KWin, tell me why exactly they can't use Enlightenment's window manager (as a base)? 'Cause, you know, Enlightenment has great Wayland support as well. Not sure if you were aware of that 'cause you only seem to know Mutter, KWin and Mir... but if you were aware, could you explain why MATE can't use Enlightenment's window manager as a drop-in replacement?
            @ElectricPrism asked for an "ELI5" answer, which is a good thing, 'cause I'm only 5.5 years old.

            I honestly don't know much about Enlightenment's window manager, or whether it could be a good drop-in replacement for use by MATE and other smaller DE development groups. I'll ask my big brother.

            Comment


            • #7
              Originally posted by GizmoChicken View Post

              @ElectricPrism asked for an "ELI5" answer, which is a good thing, 'cause I'm only 5.5 years old.
              So you were born on 29th February 1996?

              Comment

              Working...
              X