UBports Robot Logo UBports Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    Mir 1.4.0

    Scheduled Pinned Locked Moved Lomiri (was Unity8)
    5 Posts 4 Posters 1.1k Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
      Reply
      • Reply as topic
      Log in to reply
      This topic has been deleted. Only users with topic management privileges can see it.
      • A Offline
        Aurze
        last edited by

        mir 1.4.0 got announced and they are dropping stuff releated to UBports. But I'm not sure to understand the implication for UT. What does this imply for us? Can we drop deplicated API or we will need to maintaine them?
        mir announcment: https://discourse.ubuntu.com/t/mir-1-4-0-release/12198

        alan_gA 1 Reply Last reply Reply Quote 0
        • dobeyD Offline
          dobey
          last edited by

          The APIs are deprecated, not removed yet. We will need to build our version of Mir with them still enabled for now.

          In order to move away from the deprecated mirclient API, we will require implementations of certain protocol features to be done as Wayland protocol extensions (or to be implemented in a method independent of display server). We will also need either Xmir to use Wayland instead of mirclient, or we'll need to get Xwayland working.

          These are unfortunately very large tasks, so it will be a while. We can also hang back to a version of Mir which still has mirclient, once it gets removed, if it's still necessary. We are not directly bound to the Mir release schedule.

          1 Reply Last reply Reply Quote 2
          • alan_gA Offline
            alan_g @Aurze
            last edited by

            tl;dr: There's nothing to worry about, this was expected and planned for.

            The mirclient APIs used in Unity8 and 16.04 based applications is not dropped, and does not require a build-time option to enable it.

            It simply needs switching on with a configuration option at runtime. (There are many ways that can be supplied, for example, adding code to QtMir and unity-system-compositor that fakes passing this as a "command-line option" to Mir.)

            For a bit of perspective, these APIs have been deprecated for two years, and the UBports developers have been aware of that. Similarly, the Mir developers have been aware that they are used by UBports and have continued to build and test them.

            Everyone working on this software stack has always known that UBports needs to move off these APIs at some point, but that cannot happen until there is a viable alternative. And that requires moving to a more recent version of Mir (at least Mir 1.3 for this Mir support for Wayland).

            The change to "new Mir" is progressing, and is available on the "edge" channel. Delivering that will allow the migration to Wayland to start.

            There have been discussions (here and here) about this migration and, when the time comes, the Mir team has the expertise, willingness and availability to help UBport move from mirclient APIs to Wayland protocols.

            There may be a time during this transition where UBports cannot ship with the latest release of Mir, but the way forward is clear and the problems to be addressed are far smaller than ones that have already been overcome.

            ? A 2 Replies Last reply Reply Quote 8
            • ? Offline
              A Former User @alan_g
              last edited by

              🙂 Thank you, @alan_g

              1 Reply Last reply Reply Quote 0
              • A Offline
                Aurze @alan_g
                last edited by

                @alan_g wow super detail answer thanks for the detail and the explaination.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post