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

2019: Time to make Unity8 great again?

Scheduled Pinned Locked Moved Lomiri (was Unity8)
18 Posts 6 Posters 5.3k Views 4 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
      alan_g
      last edited by 29 Dec 2018, 11:21

      I've noticed a few discussions recently regarding developers getting involved in developing Unity8. I don't know all the answers myself, and don't have the free time to find them, but I think I can start a constructive discussion.

      A bit of history

      The Unity8 shell comprises a lot of inter-related projects and dependencies. These have to be coordinated and installed together, this worked best in Ubuntu 17.04 at which point it was possible to install a usable Unity8 desktop from the archive with a single command.

      When Canonical withdrew from the project they understandably stopped maintaining these projects and dropped them and a number of the dependencies from the archives. There have also been some incompatible changes to some of the dependencies.

      One of the big changes has been to the Mesa graphics drivers: Ubuntu used to carry a "Mir EGL" distro patch that enabled EGL clients to use the "mirclient API". Because Mesa changed in ways that broke that patch badly it was dropped in Ubuntu 18.04. I'll discuss this further below under "Going Wayland".

      The UBports team has done its best to maintain the projects and dependencies in the UBports repo, but this hasn't been the most urgent thing to work on and they have not dealt with everything that has changed.

      Getting started

      I've never built the majority of Unity8 components from source, not am I sure which branches are canon in the UBports source repositories. I'm sure developers could figure this out, but it would save everyone time if there were a blogpost.

      The bits I do know:

      1. The first, best hope is 18.04LTS.
        Other distros and more recent series are possible, but let's make it work in one place before fixing everywhere.
      2. The UBports repo at http://repo.ubports.com/ contains the dependencies, and needs to be added to apt sources.
        echo "deb http://repo.ubports.com/ $UBUNTU_CODENAME main" | sudo tee /etc/apt/sources.list.d/ubports.list
        wget http://repo.ubports.com/keyring.gpg -O - | sudo apt-key add -
      3. This is messy enough accidentally break your system: use test partition, VM, or secondary laptop as appropriate.
      4. There are more detailed instructions in the README: https://github.com/ubports/unity8

      Going Wayland

      This is the bit I understand best (because I work on Mir). It is also, I think the biggest cause of deterioration since 17.04.

      Unity8 was originally built using the "mirclient API" which was designed for convergence. But for "mirclient API" to be useful this needs support in client toolkits and even with Canonical pushing it this was never great. Since then, it has been dropped from GTK+ and SDL2.

      Unity8 is based on Mir and @mariogrip had done the work needed for Unity8 to run on Ubuntu 18.04 without "Mir EGL" by using Wayland instead of the "mirclient API" (which is supported by recent versions of Mir).

      However, Wayland is not a "drop-in" replacement for the "mirclient API" and there are some limitations apparent on Unity8 desktop:

      1. GTK+ applications assume CSD and add shadows which Unity8 is "not expecting". That produces weird effects, like a disconnected, second titlebar.
        There is, theoretically, a solution to this upstream: https://github.com/MirServer/mir/issues/664
      2. For X11applications the integration provided by Xwayland is even worse than that previously provided by Xmir
        Part of the solution to this is upstream: https://github.com/MirServer/mir/labels/Experimental
        2.1 But this isn't all: https://github.com/ubports/unity8/issues/56

      I am biassed by my involvement in Mir, but these are issues that an interested developer could tackle to make a significant improvement to the Unity8 desktop. In addition, they are easier to work on than Unity8 as the Mir project has significantly fewer dependencies (all of which are in the Ubuntu archives).

      Another effect of the loss of "Mir EGL" in Mesa and the consequent switch to Wayland ls that the "Mir-on-Mir" support needed to use the Unity greeter is no longer available. Some work has been done on providing a "Mir-on-Wayland" graphics platform in Mir, but that needs significant rework (it is on my list of things I want to get to, but if you fancy taking it on get in touch).

      Note: There are additional limitations to using Wayland on the phone that need to be addressed, but I'm keeping this discussion to Unity8 desktop.

      Other stuff

      Unity8 was not finished in 17.04, and quite a few of the things that were "done" need to be updated. I'm not an expert on this so I'll leave detailing a list to others.

      What I do know:

      1. The issues list: https://github.com/ubports/unity8/issues

      2019: Time to make Unity8 great again?

      I hope this provides a bit of impetus to developers interested in contributing to Unity8 to progress further. Even if this post is simply a place for potential developers to declare their interest and meet each other it will have served a purpose.

      ? D G 3 Replies Last reply 29 Dec 2018, 12:26 Reply Quote 13
      • ? Offline
        A Former User @alan_g
        last edited by 29 Dec 2018, 12:26

        🙂 Thanks for this @alan_g. And thanks for all your hard work in this area. I'd certainly love to run Unity8 on a lap/desktop rather than anything else.

        1 Reply Last reply Reply Quote 1
        • A Offline
          alan_g
          last edited by alan_g 30 Dec 2018, 16:07

          Going Wayland is going cross-distro

          One of the big changes has been to the Mesa graphics drivers: Ubuntu used to carry a "Mir EGL" distro patch that enabled EGL clients to use the "mirclient API". Because Mesa changed in ways that broke that patch badly it was dropped in Ubuntu 18.04. I'll discuss this further below under "Going Wayland".
          ...
          Unity8 is based on Mir and @mariogrip had done the work needed for Unity8 to run on Ubuntu 18.04 without "Mir EGL" by using Wayland instead of the "mirclient API" (which is supported by recent versions of Mir).

          In the OP I neglected to mention one very useful side-effect of these changes: Because Unity8 can now run without the "Mir EGL" distro patch it is no longer restricted to running on Ubuntu.

          As recently mentioned on the Mir forum Mir works on the following distros:

          • Arch (in the AUR)
          • Fedora (in the archive)
          • Ubuntu (in the archive)
          • Debian (not in the archive - yet)
          • Pop!
          • Solus
          • PostmarketOS (There are a few additional patches to be upstreamed)

          On most of these distros developers have also got Unity8 running.

          1 Reply Last reply Reply Quote 2
          • D Offline
            doniks @alan_g
            last edited by 31 Dec 2018, 07:45

            @alan_g said in 2019: Time to make Unity8 great again?:

            Another effect of the loss of "Mir EGL" in Mesa and the consequent switch to Wayland ls that the "Mir-on-Mir" support needed to use the Unity greeter is no longer available. Some work has been done on providing a "Mir-on-Wayland" graphics platform in Mir, but that needs significant rework (it is on my list of things I want to get to, but if you fancy taking it on get in touch).

            The way I understood it is that wayland replaces mir as protocol/api. So mir stays as the implementation of the server, but it goes away as an interface. So the only mir on wayland that one would need in the future is mir-the-server on wayland. Which, is just wayland (mir's implementation of a wayland server) on wayland.

            Wouldn't it then be more logical to have a greeter that is a wayland client? Or maybe the login managers from some other desktop environment could be used.

            Curious what you think.

            A 1 Reply Last reply 31 Dec 2018, 13:32 Reply Quote 0
            • A Offline
              alan_g @doniks
              last edited by 31 Dec 2018, 13:32

              @doniks said in 2019: Time to make Unity8 great again?:

              Wouldn't it then be more logical to have a greeter that is a wayland client? Or maybe the login managers from some other desktop environment could be used.

              Curious what you think.

              The Canonical design was for unity-system-compositor [USC] to be a system wide Mir server that supported both the greeter and login session based shells. Only USC would interact with the hardware, it would see the greeter and session shells as Mir clients. The session shells would use the mirclient API (a.k.a. "Mir-on-Mir") but that requires "Mir EGL" and is no longer possible.

              This architecture has a number of desirable features: only one system-wide task has to negotiate access to the hardware, and that task also controls transitions between user sessions, login screens and lock screens.

              Once Mir has a Mir-on-Wayland platform it will be possible to retain that architecture and use Wayland instead of the mirclient API.

              F 1 Reply Last reply 18 Apr 2019, 10:51 Reply Quote 1
              • dobeyD Offline
                dobey
                last edited by 25 Jan 2019, 15:02

                @alan_g said in 2019: Time to make Unity8 great again?:

                Once Mir has a Mir-on-Wayland platform it will be possible to retain that architecture and use Wayland instead of the mirclient API.

                Per our discussion on Telegram, I think the best place to start with this is to enumerate the list of Mir protocol features we depend on in Unity 8, so that we can get Wayland protocol extensions or alternate methods of use implemented.

                To start, the two things I am most aware of that we need mirclient API for, are:

                • Greeter
                • "trusted prompt sessions" (app overlays, like content-hub)

                There might be more, but I"m not sure what they are. If we could get solutions for these two implemented first though, I think we'd be a long way back toward getting a decent Unity 8 setup with the new Mir.

                1 Reply Last reply Reply Quote 2
                • F Offline
                  fossMan @alan_g
                  last edited by 18 Apr 2019, 10:51

                  @alan_g said in 2019: Time to make Unity8 great again?:

                  Once Mir has a Mir-on-Wayland platform it will be possible to retain that architecture and use Wayland instead of the mirclient API.

                  Naive question alert, sorry:
                  is it possible to estimate/ quantify the amount of work for that task in any way? E.g, how many skilled developers will need to work on this problem fulltime in order to have a solution in one year? 50, 100, 4...?

                  A 1 Reply Last reply 18 Apr 2019, 11:36 Reply Quote 0
                  • A Offline
                    alan_g @fossMan
                    last edited by 18 Apr 2019, 11:36

                    @fossMan said in 2019: Time to make Unity8 great again?:

                    @alan_g said in 2019: Time to make Unity8 great again?:

                    Once Mir has a Mir-on-Wayland platform it will be possible to retain that architecture and use Wayland instead of the mirclient API.

                    Naive question alert, sorry:
                    is it possible to estimate/ quantify the amount of work for that task in any way? E.g, how many skilled developers will need to work on this problem fulltime in order to have a solution in one year? 50, 100, 4...?

                    Almost all the code concerned is here:

                    $ wc -l src/server/graphics/nested/*
                       253 src/server/graphics/nested/buffer.cpp
                        64 src/server/graphics/nested/buffer.h
                        20 src/server/graphics/nested/CMakeLists.txt
                        54 src/server/graphics/nested/cursor.cpp
                        51 src/server/graphics/nested/cursor.h
                       225 src/server/graphics/nested/display_buffer.cpp
                       105 src/server/graphics/nested/display_buffer.h
                       442 src/server/graphics/nested/display.cpp
                       178 src/server/graphics/nested/display.h
                       183 src/server/graphics/nested/host_buffer.cpp
                        73 src/server/graphics/nested/host_buffer.h
                        54 src/server/graphics/nested/host_chain.h
                        95 src/server/graphics/nested/host_connection.h
                        50 src/server/graphics/nested/host_stream.h
                        52 src/server/graphics/nested/host_surface.h
                        49 src/server/graphics/nested/host_surface_spec.h
                       528 src/server/graphics/nested/input_platform.cpp
                        84 src/server/graphics/nested/input_platform.h
                        92 src/server/graphics/nested/ipc_operations.cpp
                        48 src/server/graphics/nested/ipc_operations.h
                       825 src/server/graphics/nested/mir_client_host_connection.cpp
                       134 src/server/graphics/nested/mir_client_host_connection.h
                        74 src/server/graphics/nested/native_buffer.h
                       234 src/server/graphics/nested/nested_display_configuration.cpp
                        78 src/server/graphics/nested/nested_display_configuration.h
                        35 src/server/graphics/nested/passthrough_option.h
                       227 src/server/graphics/nested/platform.cpp
                       117 src/server/graphics/nested/platform.h
                      4424 total
                    

                    That needs re-implementing to use Wayland protocol extensions instead of the mirclient API.

                    It isn't a lot of code, and not a lot of work. But it does need someone that can read mirclient code and write Wayland code. I've done that a few times (for the "internal" clients in the example shells) and the concepts correspond well.

                    There are few other parts of the system that would need touching (e.g. the configuration to set it up) but that is less of a problem.

                    I think it would take me a couple of days (but the unexpected could happen). However, that's probably the fastest it could be: there are not many that know the Mir codebase as well as I do.

                    tl;dr: Depending on the developer's background, anywhere from a few days to a month.

                    1 Reply Last reply Reply Quote 5
                    • F Offline
                      fossMan
                      last edited by fossMan 18 Apr 2019, 14:10

                      Thanks @alan_g.
                      What exactly is the "mirclient API", is that an abstraction or a specific set of files? Could you give a small example e.g a line of code showing dependence on that API, and perhaps how a Wayland extension could replace it?

                      A 1 Reply Last reply 18 Apr 2019, 14:42 Reply Quote 0
                      • A Offline
                        alan_g @fossMan
                        last edited by alan_g 18 Apr 2019, 14:42

                        @fossMan said in 2019: Time to make Unity8 great again?:

                        What exactly is the "mirclient API", is that an abstraction or a specific set of files? Could you give a small example e.g a line of code showing dependence on that API, and perhaps how a Wayland extension could replace it?

                        The mirclient API is the API provided by libmirclient.so. It is the API through which Mir proposed to support "Convergent" application toolkits. There are various bits of UBports relying on this API that need rework to Wayland (so learning to do that will remain useful after this exercise).

                        Here's some mirclient API code:

                                    Surface surface{mir_connection_create_render_surface_sync(DecorationProvider::connection, width, height)};
                        
                                    auto const buffer_stream =
                                        mir_render_surface_get_buffer_stream(surface, width, height, mir_pixel_format_xrgb_8888);
                        
                                    auto window = WindowSpec::for_gloss(DecorationProvider::connection, width, height)
                                        .set_fullscreen_on_output(output_id)
                                        .set_event_handler(&handle_event_for_background, this)
                                        .add_surface(surface, width, height, 0, 0)
                                        .set_name(wallpaper_name).create_window();
                        

                        and some equivalent Wayland code:

                                ctx.surface = wl_compositor_create_surface(globals.compositor);
                        ...
                                ctx.shell_surface = wl_shell_get_shell_surface(globals.shell, ctx.surface);
                                wl_shell_surface_set_fullscreen(
                                    ctx.shell_surface,
                                    WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT,
                                    0,
                                    ctx.output.output);
                        ...
                                auto const shm_pool = make_scoped(
                                    make_shm_pool(globals.shm, stride * height, &ctx.content_area),
                                    &wl_shm_pool_destroy);
                        
                                ctx.buffer = wl_shm_pool_create_buffer(
                                        shm_pool.get(),
                                        0,
                                        width, height, stride,
                                        WL_SHM_FORMAT_ARGB8888);
                        

                        https://github.com/MirServer/mir/pull/669/files#diff-ea35a63c157fb0d09e5713c6ee0b1dbe

                        F 1 Reply Last reply 18 Apr 2019, 17:19 Reply Quote 2
                        • F Offline
                          fossMan @alan_g
                          last edited by fossMan 18 Apr 2019, 17:19

                          @alan_g said in 2019: Time to make Unity8 great again?:

                          The mirclient API is the API provided by libmirclient.so.

                          Thanks for the example. Is there any way to download an example of a libmirclient.so file without installing anything? The closest I got was a mention on this Ubuntu package

                          EDIT: or perhaps there is some documentation of the libmirclient API in order to understand better exactly what parts of the code is addressing the API?

                          A 1 Reply Last reply 20 Apr 2019, 09:05 Reply Quote 0
                          • A Offline
                            alan_g @fossMan
                            last edited by 20 Apr 2019, 09:05

                            @fossMan https://mir-server.io/doc/group__mir__toolkit.html

                            1 Reply Last reply Reply Quote 1
                            • F Offline
                              fossMan
                              last edited by 21 Apr 2019, 20:35

                              I would like to look at these issues but can't spare the focus time until start of June.

                              A 1 Reply Last reply 24 Apr 2019, 14:08 Reply Quote 0
                              • A Offline
                                alan_g @fossMan
                                last edited by 24 Apr 2019, 14:08

                                @fossMan said in 2019: Time to make Unity8 great again?:

                                I would like to look at these issues but can't spare the focus time until start of June.

                                I imagine there will still be issues left for you when you have the time. 8-)

                                dobeyD 1 Reply Last reply 24 Aug 2019, 17:15 Reply Quote 2
                                • dobeyD Offline
                                  dobey @alan_g
                                  last edited by 24 Aug 2019, 17:15

                                  @alan_g I see in the Mir 1.4.0 release discourse mention of the layer-shell extension. If I understand correctly how this extension works, we should be able to use it for re-implementing the trusted overlays, no?

                                  If we could do that, and get it done soon, that would be a huge step forward in being able to use unity8 on wayland.

                                  A 1 Reply Last reply 25 Aug 2019, 09:35 Reply Quote 1
                                  • A Offline
                                    alan_g @dobey
                                    last edited by 25 Aug 2019, 09:35

                                    @dobey said in 2019: Time to make Unity8 great again?:

                                    @alan_g I see in the Mir 1.4.0 release discourse mention of the layer-shell extension. If I understand correctly how this extension works, we should be able to use it for re-implementing the trusted overlays, no?

                                    I agree we should map out Wayland protocols that can help replace mirclient functionality. But in this specific case, I don't think layer-shell addresses the same concerns as trusted prompts, so I don't immediately see how you imagine using it.

                                    I'll have a closer look at this idea after the holiday weekend to see what I've missed.

                                    1 Reply Last reply Reply Quote 0
                                    • G Offline
                                      GizmoChicken @alan_g
                                      last edited by 12 Dec 2019, 04:27

                                      @alan_g said in 2019: Time to make Unity8 great again?:

                                      2019: Time to make Unity8 great again?

                                      Given recent progress, how about 2020Q1: Time to make Unity8 great again?

                                      A 1 Reply Last reply 14 Jan 2020, 17:51 Reply Quote 0
                                      • A Offline
                                        alan_g @GizmoChicken
                                        last edited by 14 Jan 2020, 17:51

                                        @GizmoChicken said in 2019: Time to make Unity8 great again?:

                                        Given recent progress, how about 2020Q1: Time to make Unity8 great again?

                                        I like it! Maybe we can just rename this thread?

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