Canonical Voices

Posts tagged with 'mir'

Alan Griffiths

Mir release 0.28

[reposted from https://community.ubuntu.com/t/mir-release-0-28/545 comments are enabled there, and disabled here]

Mir 0.28

We are pleased to announce that Mir 0.28 has been released and is available in Ubuntu 17.10 (Artful).

As the content (and even the name) of this release has changed over the time we’ve been working towards it now is probably a good time to reflect on what it is, and what it isn’t after all.

What is in Mir 0.28?

There is now a stable server ABI

This simplifies the use of “Mir snaps” making it possible to release new library versions without breaking servers.

One of the barriers to the adoption of Mir has been the potential for Mir releases to break downstream projects that depend on a stable ABI. This is provided by libmiral, which is now part of Mir.

The Yunit project which uses Mir as part of its graphics stack has already started migrating code to use libmiral for this reason.

The start of Wayland support

The desktop community has adopted Wayland as the client-server protocol of choice for replacing X11. This is already supported by several server implementations (Weston, Kwin and Mutter are the best known). By providing Wayland support we will make Mir servers compatible with the various toolkits and libraries that already have Wayland backends.

Our MVP goal for Mir 0.28 has been to support a Wayland client with a single fullscreen surface. We have slightly exceeded this goal in 0.28 as you can see from this short video:

https://www.youtube.com/watch?v=sfcZrpkc2NU

We will continue to expand on this Wayland support in future releases.

The MirAL shells are part of Mir

The miral-kiosk shell is used by the mir-kiosk-snap to provide graphics support on UbuntuCore. This release includes a number of improvements to miral-kiosk based on feedback from potential users.

The miral-shell is now the canonical example of writing a Mir server. We’ve dropped several older examples that used other APIs (and reworked mir_demo_server to fit the new server APIs).

There is a (currently unstable) API for “graphics platform” plugins

We had planned to stabilize the graphics platform API and ABI before publishing it but we had to change that plan. Canonical no longer has the infrastructure to test and maintain the “android platform”. However there is was interest from UBports both in continuing to support the “android platform” and for developing a “Wayland platform”.

What is NOT in Mir 0.28?

We have not upstreamed Mesa distro patches

These patches support “Mir EGL” which forms part of the Mir client API. With the adoption of Wayland (and Wayland EGL) it looks likely that these will not have a long term future and upstreaming a wasted effort.

This should also become less of an issue as it only affects EGL clients using the legacy Mir client APIs. Software rendering, Xmir and Xwayland clients will work without these patches.

Read more
Alan Griffiths

that which we call a rose…

For the last six months we’ve been working on, and talking about “Mir 1.0”.

But today’s Mir release is not going to be called “1.0” it will be called “0.28”. The code is the same, just the name has changed.

Read more
Alan Griffiths

Custom compositing in Mir servers

Although Mir 1.0 hasn’t quite shipped yet my thoughts are turning to what we do next. One of the work items that got paused was removing the mirserver dependencies from QtMir.

While Canonical isn’t using QtMir, the purpose of the affected code is still relevant. It enables custom compositing for transitions and other effects and this is of continuing, wider, interest.

Clearly Qt isn’t the only framework that might want to customize the way the server composites the scene and Mir ought to support a range of options through a stable, well thought out API.

We need to start somewhere. A few conversations over the past few days have identified a couple of options: GDK4 and Clutter.

I don’t know enough yet to prioritise or plan this work, but input from anyone interested in helping get one of these toolkits working would be great.

Read more
Alan Griffiths

Mir related ppas

Mir staging ppa

A few weeks ago I was reminded of the “Mir staging ppa” and saw that, with the discontinuation of Unity8 it had fallen into disuse. After considering deleting it I eventually removed some Ubuntu series that are no longer supported and added MirAL trunk.

That means that for Xenial, Zesty and Artful you can get the latest development version of Mir and MirAL like this:

sudo add-apt-repository ppa:mir-team/staging
sudo apt-get update
sudo apt-get upgrade

miral-release ppa

Now for the Internet of Things we are using UbuntuCore16 and snaps, but occasionally it is useful to have debs too. For Mir it is easy to use the underlying 16.04LTS (Xenial) archive, but MirAL isn’t in that archive.

To make up for that I’ve created a “miral-release” ppa containing the latest release of MirAL built for both Xenial and Zesty. Vis:

sudo add-apt-repository ppa:alan-griffiths/miral-release
sudo apt-get update
sudo apt-get upgrade

 

Read more
Alan Griffiths

Mir release 0.27

Mir release 0.27/MirAL release 1.4

This is an interim development release of Mir and MirAL to Ubuntu 17.10 (Artful) that delivers many of the features that were work-in-progress when we needed to restructure the project. The Mir release notes are here: https://launchpad.net/mir/0.27/0.27.0.

The MirAL 1.4 release exposes a few new features and removes support for Mir versions that are no longer supported:

  • Support for passing messages to enable Drag & Drop
  • Support for client requested move
  • Port to the undeprecated Mir APIs
  • Added “–cursor-theme” option when configuring a cursor theme
  • Drop support for Mir versions before 0.26

There will be further Mir releases culminating in a Mir 1.0 release before the Ubuntu 17.10 (Artful) feature freeze in August.

Read more
Alan Griffiths

Mir: the new order

The Past

The Mir project has always been about how best to develop a shell for the modern desktop. It was about addressing concerns like a security model for desktop environments; convergence (which has implications for app lifecycles); and, making efficient use of modern hardware. It has never been only about Unity8, that was just the first of (hopefully) many shells written using Mir. To that end, the Mir developers have tried to ensure that the code wasn’t too tightly coupled to Unity8 (e.g. by developing demo servers with alternative behaviors).

There have been many reasons that no other shells used Mir but to tackle some of them I started a “hobby project” (MirAL) last year. MirAL aimed to make it easier to build shells other than Unity8 with Mir, and one of the examples I produced, miral-kiosk, proved important to Canonical’s support for graphics for the “Internet of Things”. Even on the Internet of Things Mir is more than just a way of getting pixels onscreen, it also fits the security model needed. That secures a future for Mir at Canonical.

The Present

In Canonical the principle target for Mir is now Ubuntu Core, and that is currently based on the 16.04LTS. We’ve recently released Mir 0.26.3 to this series and will be upgrading it to Mir 1.0 when that comes out.

Outside Canonical there are other projects that are making use of Mir.

UBports is taking forward the work begun by Canonical to support phones and tablets. Their current stack is based on an old release of Mir (0.17) but they are migrating to Ubuntu 16.04LTS and will get the latest release of Mir with that.

Yunit is taking forward the work begun by Canonical on “convergence”. They are still in an exploratory phase, but the debs they’ve created for Debian Unstable use the current Mir 0.26 release.

As reported elsewhere there have been discussions with other projects who are interested in using Mir. It remains to see if, and in what way, those discussions develop.

The Future

For all of these projects the Mir team must be more responsive than it has been to the needs of those outside Canonical. I think, with the work done on MirAL, much of the technical side of that has been addressed. But we still have to prove ourselves in other ways.

There’s a new (0.27) release of Mir undergoing testing for release to the Ubuntu 17.10 series. This delivers a lot of the work that was “in progress” before Canonical’s focus shifted from Unity8 to miral-kiosk and marks the point of departure from our previous plans for a Mir 1.0. Mir 0.27 will not be released to other series, as we expect to ship Mir 1.0 in 17.10.

The other thing 0.27 offers is based on the efforts we’ve seen in UBports (and a PR from a former Mir developer that has joined the project): we’ve published the APIs needed to develop a “mir platform” out of the Mir source tree. That means, for example, developing a mir-on-wayland platform doesn’t require forking the whole of Mir. One specific platform that is now out-of-tree is the “mir-on-android” platform – from my experience with MirAL I know that having a real out-of-tree project helps prove things really work.

In addition, while we won’t be releasing Mir 0.27 to 17.04, I’ve included testing there, along with the Unity8 desktop to ensure that all the features required by a “real shell” remain intact.

Beyond Mir 0.27 the plan towards 1.0 diverges from past discussions. We are no longer planning to remove deprecated functions from the libmirclient ABI, instead we are working towards supporting Wayland clients directly.

Read more
Alan Griffiths

making-mesa

In order to trace a problem[1] in the Mir stack I needed to build mesa to facilitate debugging. As the options needed were not entirely obvious I’m blogging the recipe here so I can find it again next time.

$ apt source libgl1-mesa-dri
$ cd mesa-17.0.3
$ QUILT_PATCHES=debian/patches/ quilt push -a
$ sudo mk-build-deps -i
$ ./configure --with-gallium-drivers= --with-egl-platforms=mir,drm,rs
$ make -j6
$ sudo make install && sudo ldconfig

[1] The stack breaking with EGL clients when the Mir server is running on a second host Mir server that is using the mesa-kms plugin and mesa is using the intel i965 driver. (LP: #1699484)

Read more
Alan Griffiths

Mir release 0.26.3

Mir 0.26.3 for all!

By itself Mir 0.26.3 isn’t a very interesting release, just a few minor bugfixes: [https://launchpad.net/mir/0.26/0.26.3]

The significant thing with Mir 0.26.3 is that we are making this version available across the latest releases of Ubuntu as well as 17.10 (Artful Ardvark). That is: Ubuntu 17.04 (Zesty Zapus), Ubuntu 16.10 (Yakkety Yak) and, last but not least, Ubuntu 16.04LTS (Xenial Xerus).

This is important to those developing Mir based snaps. Having Mir 0.26 in the 16.04LTS archive removes the need to build Mir based snaps using the “stable-phone-overlay” PPA.

Read more
Alan Griffiths

Fairer than Death

The changes at Canonical have had an effect both on the priorities for the Mir project and on the resources available for future development. We have been meeting to make new plans. In short:

Mir is alive, there are Canonical IoT projects that use it. Work will continue on Mir to support these and on cleaning and upstreaming the distro patches Ubuntu carries to support Mir.

Canonical are no longer working on a desktop environment or phone shell. However we will maintain the existing support Mir has for compositing and window management. (We’re happy to receive PRs in support of similar efforts.)

Read more
Alan Griffiths

Why Mir

Mir provides a framework for integration between three parts of the graphics stack.

These parts are:

  1. The drivers that control the hardware
  2. The desktop environment or shell
  3. Applications with a GUI

Mir currently works with mesa-kms graphics, mesa-x11 graphics or android HWC graphics (work has been done on vulkan graphics and is well beyond proof-of-concept but hasn’t been released).

Switching the driver support doesn’t impact the shell or applications. (Servers will run unchanged on mesa, on X11 and android.) Mir provides “abstractions” so that, for example, user input or display configuration changes look the same to servers and client applications regardless of the drivers being used.

Mir supports writing a display server by providing sensible defaults for (e.g.) positioning tooltips without imposing a desktop style. It has always carried example programs demonstrating how to do “fullscreen” (kiosk style), traditional “floating windows” and “tiling” window management to ensure we don’t “bake in” too many policies.

Because the work has been funded by Canonical features that were important to Ubuntu Phone and Unity8 desktop have progressed faster and are more complete than others.

When Mir was started we needed a mechanism for client-server communications (and Wayland wasn’t in the state it is today). We did something that worked well enough (libmirclient) and, because it’s just a small, intentionally isolated part of the whole, we could change later. We never imagined what a “big deal” that decision would become.


[added]

Seeing the initial reactions I can tell I made a farce of explaining this. I’ll try again:

For the author of a shell what Mir provides is subtly but significantly different from a set of libraries you can use to build on: It provides a default shell that can be customized.

Read more
Alan Griffiths

A new hope

Disclaimer: With the changes in progress at Canonical I am not currently in a position to make any commitment about the future of Mir.

It is no secret that I think there’s value to the Mir project and I’d like it to be a valued contribution to the free software landscape.

I’ve written elsewhere about my efforts to make it easy to use Mir for making desktop, phone and “Internet of Things” shells, I won’t repeat that here beyond saying “have a look”.

It is important to me that Mir is GPL. That makes it a contribution to a “commons” that I care about.

The dream of convergence dies hard. Canonical may have abandoned it, but I hope it survives. A lot of the issues have been tackled and knowledge gained.

I read that UBPorts will be using Mir “for the time being”. They sensibly don’t want to maintain Mir and are planning a migration to an (unidentified) Wayland compositor.

However, we can also see from G+ Mark Shuttleworth is planning to keep “investing in Mir” for the Internet of Things.

This opens up an interesting possibility: there’s no obvious technical reason that Mir could not support clients using libwayland directly. It would take some research to confirm this but I can’t foresee anything technical blocking such an approach.

There could be some benefits to Canonical from this: the current design of Mir client-server interation makes sense in a traditional Debian (or RPM) repository based world, but less so for Snap (or Flatpak).

In a traditional environment where the libraries are a shared resource updates simply need to maintain ABI compatibility to work with existing clients. That makes it possible to keep Mir server and client and server libraries “in step” while making incompatible changes to the communications protocol.

However with Snaps the client and server “snap”s package the libraries they use with the applications.That presents issues for keeping them in step. These issues are soluble but create an additional burden for Mir, server and client developers. Using a protocol based solution would ease this burden.

For the wider community native support for Wayland clients in Mir would make the task of toolkit maintainers and others simpler.

If Canonical could be persuaded to add this feature to Mir and/or maintain it in the project would anyone care?

Is anyone else willing to help with such a feature?

Read more
Alan Griffiths

The end of a dream?

We read in the press that Canonical has pulled out of the dream of “convergence”. With that the current support for a whole family of related projects dies.

That doesn’t mean that the dream has to die, but it does mean changes.

I hope the dream doesn’t die, because Canonical has done a lot of the “heavy lifting” – the foundations are laid, the walls are up, we have windows, plumbing and power. But we’re lacking the paintwork and there’s no buyer.

My expertise is developing working software and I’m going to donate some of that to the dream.

Stable Intermediate Forms is an important principle – keep things working while making changes. If you throw away a large chunk intending to replace it you’ll find re-integration really, really hard. Do things gradually!

So, don’t simply fork Unity8 and plan to get it working on Wayland. You’ll end up with a single wall that falls over before you’ve replaced the rest of the building. (Sorry, I went back to “metaphor”.)

Take the whole infrastructure etc. and keep it in place until any replacements are demonstrably ready.

The Elephant in the room

Many have issues with the way Mir has been presented to the community, but in the opinion of the developers it is a good piece of software and not inherently incompatible with Wayland. (Just look at what the developers have written about it especially the early posts that addressed this directly.)

There are two plausible evolutions of the dream that reconcile Mir with Wayland.

Plan 1: (my recommendation) Add support to libmirserver for Wayland clients in parallel to the existing protocol. Once this is working this either junk libmirclient or rework its interaction with libmirserver.

Plan 2: Implement an analog of QtMir/MirAL on your choice of Wayland server. Then transition Unity8 to these and junk Mir.

I can’t guarantee that my recommendation of “plan 1” isn’t biased by my history with the Mir project, clearly I know its potential better than that of competing projects and I would find developing these easier than someone new to the code. In then end, the choice will depend on who takes on the work and what they can achieve most effectively.

Read more
Alan Griffiths

MirAL 1.3.2

There’s a bugfix MirAL release (1.3.2) available in ‘Zesty Zapus’ (Ubuntu 17.04) and the so-called “stable phone overlay” ppa for ‘Xenial Xerus’ (Ubuntu 16.04LTS). MirAL is a project aimed at simplifying the development of Mir servers and particularly providing a stable ABI and sensible default behaviors.

The bugfixes in 1.3.2 are:

In libmiral a couple of “fails to build from source” fixes:

Fix FTBFS against Mir < 0.26 (Xenial, Yakkety)

Update to fix FTBFS against lp:mir (and clang)

In the miral-shell example, a crash fixed:

With latest zesty’s libstdc++-6-dev miral-shell will crash when trying to draw its background text. (LP: #1677550)

Some of the launch scripts have been updated to reflect a change to the way GDK chooses the graphics backend:

change the server and client launch scripts to avoid using the default Mir socket (LP: #1675794)

Update miral-xrun to match GDK changes (LP: #1675115)

In addition a misspelling of “management” has been corrected:

miral/set_window_management_policy.h

Read more
Brandon Schaefer

When Choosing a Backend Fails

There was a recent GDK release into zesty that now probes for Mir over X11. This can cause issues when still using an X11 desktop such as Unity7 when a Mir server is running at the same time.

A common way to test Mir is to run it on top of X, which is called Mir-on-X. This means there are now two display servers running at the same time.

An example of an issue this can cause is gnome-terminal-server. It will attempt to spawn its clients on Mir instead of X11 once the Mir server is opened. You now attempt to spawn a new terminal which causes the gnome-terminal-server to crash since it now tries to spawn on Mir but you already spawned terminals on X. As you can imagine this is frustrating to your workflow!

A simple workaround is to add this to your ~/.profile:

if [ "$XDG_CURRENT_DESKTOP" = "Unity:Unity7" ]; then
    dbus-update-activation-environment --systemd GDK_BACKEND=x11
fi

Depending on your desktop the “Unity:Unity7” bit will change.

As more toolkits will start to pick other display servers as their first pick more of these issues will become possible. Other environment variables to consider:

SDL_VIDEODRIVER
QT_QPA_PLATFORM

A bit more detail on the issue can be found here:

Choosing a Backend

Read more
Cemil Azizoglu

Hi, I’ve been wanting to have a blog for a while now. I am not sure if I’ll have the time to post on a regular basis but I’ll try.

First things first : My name is Cemil (pronounced JEH-mil), a.k.a. ‘camako’ on IRC – I work as a developer and am the team-lead in the Mir project.

Recently, I’ve been working on Mir 1.0 tasks, new Mesa EGL platform backend for Mir, Vulkan Mir WSI driver for Mesa, among other things.

Here’s something pretty for you to look at for now :

https://plus.google.com/113725654283519068012/posts/8jmrQnpJxMc

-Cemil

Read more
Alan Griffiths

MirAL 1.3.1

There’s a bugfix MirAL release (1.3.1) available in ‘Zesty Zapus’ (Ubuntu 17.04) and the so-called “stable phone overlay” ppa for ‘Xenial Xerus’ (Ubuntu 16.04LTS). MirAL is a project aimed at simplifying the development of Mir servers and particularly providing a stable ABI and sensible default behaviors.

Unsurprisingly, given the project’s original goal, the ABI is unchanged.

The bugfixes in 1.3.1 are:

In libmiral a focus management fix:

When a dialog is hidden ensure that the active window focus goes to the parent. (LP: #1671072)

In the miral-shell example, two crashes fixed:

If a surface is deleted before its decoration is painted miral-shell can crash, or hang on exit (LP: #1673038)

If the specified “titlebar” font doesn’t exist the server crashes (LP: #1671028)

In addition a misspelling of “management” has been corrected:

SetWindowManagmentPolicy => SetWindowManagementPolicy

Read more
Alan Griffiths

Mir and Zesty

Mir is continuing to make progress towards a 1.0 release and, meanwhile, Zesty Zapus (Ubuntu 17.04) is continuing to make progress towards final freeze.

Currently the version of Mir in Zesty is 0.26.1 and we’re not planning any major changes for the 17.04 series. We’re probably going to make a bugfix release (0.26.2). The other possibility is that work on supporting hybrid graphics is completed in time for adequate testing for 17.04. In the latter case we’ll be releasing Mir 0.27 to get that shipped.

For this and other reasons it isn’t yet clear whether there will be a 0.27 release before we move to 1.0.

The significance of a 1.0 release is that it will be the time we break the mirclient ABI and delete a lot of deprecated APIs, which will have a significant effect on downstream projects. We’ve tried to prepare by marking the deprecations in 0.26 and updating downstream projects accordingly. But while this preparation means that most downstream projects “only need recompiling” this is something we want to do at the start of a release cycle, not at the end.

The argument for a 0.27 release is that there is functionality we want to release and that this can be done without the disruption of an ABI break. So even if we don’t release 0.27 for 17.04 we may well do so once 17.10 is “open” in order to make this work available for Unity8 developers to use.

Either way, sometime early in the 17.10 cycle we’re going to release Mir 1.0. This will clear the way for Mir support in Mesa and Vulkan.

Read more
Alan Griffiths

MirAL 1.3

There’s a new MirAL release (1.3.0) available in ‘Zesty Zapus’ (Ubuntu 17.04) and the so-called “stable phone overlay” ppa for ‘Xenial Xerus’ (Ubuntu 16.04LTS). MirAL is a project aimed at simplifying the development of Mir servers and particularly providing a stable ABI and sensible default behaviors.

Unsurprisingly, given the project’s original goal, the ABI is unchanged.

The changes in 1.3.0 fall are:

Support for “workspaces”

This is part of the enabling “workspaces” for Unity8 desktop. MirAL doesn’t provide fancy transitions and spreads, but you can see some basic workspace switching in the miral-shell example program:

$ apt install miral-examples
$ miral-app

There are four workspaces (corresponding to F1-F4) and you can switch using Meta-Alt-[F1|F2|F3|F4], or switch taking the active application to the new workspace using Meta-Ctrl-[F1|F2|F3|F4].

Support for “previous window in application”

You can now use Alt-Shift-` to switch to the previous in an application.

miral-shell adds a background

miral-shell now uses its background for a handy guide to the available keyboard shortcuts.

Bug fixes

Two bug fixes related to shutdown problems: one deals with a possible race in libmiral code, the other works around a bug in Mir.

  • [libmiral] Join internal client threads before server shutdown (LP: #1668651)
  • [miral-shell] Workaround for crash on exit (LP: #1667645)

Read more
Alan Griffiths

mircade-snap

mircade, miral-kiosk and snapcraft.io

mircade is a proof-of-concept game launcher for use with miral-kiosk. It looks for installed games, works out if they use a toolkit supported by Mir and allows the user to play them.

miral-kiosk is a proof-of-concept Mir server for kiosk style use. It has very basic window management designed to support a single fullscreen application.

snapcraft.io is a packaging system that allows you to package applications (as “snaps”) in a way that runs on multiple linux distributions. You first need to have snapcraft installed on your target system (I used a dragonboard with Ubuntu Core as described in my previous article).

The mircade snap takes mircade and a few open games from the Ubuntu archive to create an “arcade style” snap for playing these games.

Setting up the Mir snaps

The mircade snap is based on the “Mir Kiosk Snaps” described here.

Mir support on Ubuntu Core is currently work in progress so the exact incantations for installing the mir-libs and mir-kiosk snaps to work with mircade varies slightly from the referenced articles (to work around bugs) and will (hopefully) change in the near future. Here’s what I found works at the time of writing:

$ snap install mir-libs --channel edge
$ snap install mir-kiosk --channel edge --devmode
$ snap connect mir-kiosk:mir-libs mir-libs:mir-libs
$ sudo reboot

Installing the mircade-snap

I found that installing the mircade snap sometimes ran out of space on the dragonboard /tmp filesystem. So…

$ TMPDIR=/writable/ snap install mircade --devmode --channel=edge
$ snap connect mircade:mir-libs mir-libs:mir-libs
$ snap disconnect mircade:mir;snap connect mircade:mir mir-kiosk:mir
$ snap disable mircade;sudo /usr/lib/snapd/snap-discard-ns mircade;snap enable mircade

Using mircade on the dragonboard

At this point you should see an orange screen with the name of a game. You can change the game by touching/clicking the top or bottom of the screen (or using the arrow keys). Start the current game by touching/clicking the middle of the screen or pressing enter.

Read more
kevin gunn

1)Put the latest ubuntu-core image for dragonboard on boot (you’ll want a screen and keyboard at least)

You can find the image here http://releases.ubuntu.com/ubuntu-core/16/

Make sure you’re on the latest with the following


ssh$ snap refresh core

 

2)Then install the mir-libs and mir-kiosk

 

ssh$ snap install mir-libs --channel=edge
ssh$ snap install mir-kiosk --channel=edge
ssh$ snap install ubuntu-app-platform

 

 

3)Using the snap built from this branch

https://code.launchpad.net/~osomon/webbrowser-app/mirkiosk-snap  

This particular snap

https://code.launchpad.net/~osomon/+snap/webbrowser-mirkiosk/+build/16501

Seemed to work find, download copy over and install


ssh$ snap install webbrowser-app*.snap --devmode --dangerous

 

4) NOTE: because of bug  you have to do the following, hopefully the pull request will get merged soon and this step we can remove

 

ssh$ snap disconnect webbrowser-app:mir
ssh$ snap disconnect webbrowser-app:platform
ssh$ snap connect webbrowser-app:mir mir-kiosk:mir
ssh$ snap connect webbrowser-app:platform ubuntu-app-platform:platform
ssh$ snap disable webbrowser-app
ssh$ snap enable webbrowser-app

 

5) Now launch and use


$ webbrowser-app

 

If you should experience a crash of the web browser, just restart with the same command. Also, you will see some spew at the console you may ignore from the browser launching related to audio and Qt stuff.

 

Debugging: if you should find things aren’t working as expected, as in you do not see the web browser. Try rebooting first, which should auto launch mir-kiosk, then repeat the connection process and launching the browser. If that still doesn’t work, inspect all the connections via ssh$ snap interfaces and make sure mir-kiosk:mir-libs, webbrowser-app:mir-kiosk, webbrowser-app:ubuntu-app-platform, webbrowser-app:mir-libs are all connected as expected. Feel free to ping me or others on freenode at #snappy or #ubuntu-unity or #ubuntu-mir

Read more