Mir News: 17th August 2018

[alan_g]

Mir News

I’ve decided to change the name of our round-up post. (I think “This Week in Mir” is misleading.)

ppa:mir-team/dev

We’ve had some interesting developments landing on master.

• Support for xdg-shell (stable)
  This work by @sophie-w will make it easy to use Mir with the current and future generations of client toolkits.
• Partial Nvidia support has landed
  This isn’t everything yet. @raof has got the “platform” working, so Mir can run on Nvidia drivers. But we still needs to complete wiring up the support for GL clients.
• A mechanism to configure Wayland extension protocols
  This allows shell developers and deployers to specify which extension protocols to enable.

We’ve also fixed a few bugs.

There are two things “of interest” that have not progressed:

• X11 support
  The core team has not got to this yet. What exists is a community contribution by @mariogrip. This remains “experimental” as there are outstanding issues to resolve before it is ready.
• Remote desktop support
  The core team has not got to this yet. But there are a couple of community efforts in this space:
  • https://github.com/MirServer/mir/issues/467 “Remote desktop support”
  • https://forums.ubports.com/topic/1389/reverse-convergence-view-control-your-phone-from-computer-like-vnc-rdp

snapcraft

• The mir-kiosk snap is being used with positive feedback in the form of feature requests.
• The egmde snap has proved useful
  The availability of an easy to install Mir desktop led to some good bug reports by @GizmoChicken who tested Mir on some configurations the Mir team did not have to hand.

There are still a few “bumps” in the story of developing client snaps. @greyback has been working on progressing these.

• Snaps and sharing Mir’s Wayland socket
  With the benefit of feedback and hindsight we can improve the way that Wayland clients connect to Wayland servers when both are confined snaps. This work will pave the way for them to “autoconnect”.
• The way that the GL stack is deployed is problematic
  Currently both servers and clients need to contain drivers for every device they run on. The discussions about how best to avoid this are ongoing.
• Developing Xwayland based clients requires enabling the experimental “layouts” core feature
  Hopefully this will ship soon.

Desktop

There’s a recent announcement by lubuntu that they plan to migrate to using Mir: “… We are going to do this by porting Openbox to use the Mir display server, Drew DeVault’s QtLayerShell, and other associated bits.” A great choice!

Phone

One of the UBports developers has started work on updating their “android” Mir platform to the current version of Mir.

When complete this will enable them to run a modern (Wayland capable) Mir on the phone with obvious benefits to their goal of supporting desktop applications.

[pharaone]

I hadn’t heard about Lubuntu yet, you made me happy!

[aplaice]

@alan_g

Desktop
There’s a recent announcement by lubuntu that they plan to migrate to using Mir: “… We are going to do this by porting Openbox to use the Mir display server, Drew DeVault’s QtLayerShell, and other associated bits.” A great choice!

It’s great that more projects are deciding to base themselves on Mir, for ease of transition to Wayland! (I assume that the idea of MATE using Mir is still under consideration, since I haven’t read any further news on it (?).)

I have a slightly tangential question (please feel free to ignore it, if it’s off-topic): given that Mir is written in C++, and given that unlike C, C++ does not allow for an easy FFI to most other languages, will WMs using Mir be effectively limited to C++, or will developing other language bindings not be too difficult? I’m asking particularly in the context of projects like XMonad (using haskell) or Stumpwm (common lisp), but it’s also relevant to the Wayland port of Openbox, since it was originally written just in C.

(Yes, I’m aware that wlroots is in pure C, but variety is always nice.)

[alan_g]

@aplaice

I have a slightly tangential question (please feel free to ignore it, if it’s off-topic): given that Mir is written in C++, and given that unlike C, C++ does not allow for an easy FFI to most other languages, will WMs using Mir be effectively limited to C++, or will developing other language bindings not be too difficult?

Until someone actually does it this is speculation, but I have written C, Java and Python interfaces to C++ and have some idea of the issues.

The miral API would need a suitable “wrapper” and this would require care if it is to feel natural in the target language. But it should be feasible for someone familiar with such work, and wouldn’t need continual rework to track changes to the API.