@jonius said in Introducing Miroil:

@alan_g does that mean no need for a PR from my side?

Well, I've fixed the compile error, but you modernized the code as well. I think that's still worth a PR.

@aury88 said in Introducing Miroil:

@jonius i tried again after the git pull but obtain the same error

Sorry, you'll need a git fetch first.

@aury88 I'm not sure when I'll be at a computer where I can fix this. In the meantime you could google enough git magic to cherry-pick @jonius's fix.

UPDATE: I've pushed a fix for the build error. There's still the test failure noted above.

@Aury88 You can get the fix with git pull

@jonius can you PR your fix? It looks to tidy up the cmake code too.

@gizmochicken said in Ubuntu Touch Q&A 92 Saturday 16th January at 19:00 UTC:

QUESTION: I realize you have many things on your plate now, and so I'm not asking about your immediate plans, but would you consider bringing Lomiri to Ubuntu Core sometime in the future?

Ubuntu Core only supports confined snaps. (Not debs, "classic" snaps, or other packaging formats.)

Running any shell under snap confinement is an unsolved problem that I and others are working on. That needs to be addressed before it would be feasible to deploy Lomiri this way.

@kevin before you can install on a device you need a "port" for that device.

There are some "unsupported" ports (typically ones that haven't been completed).

The entry point to the porting process is: https://docs.halium.org/en/latest/porting/first-steps.html

@phoenixlandpirat said in What about Matrix?:

Wayland had much if anything to do with flutter

Flutter is similar to toolkits like GTK, Qt, SDL and so on. The application code talks to Flutter and Flutter talks to the graphical shell. Flutter has "platforms" for various stacks e.g. Android and iOS. The Flutter "Linux" platform will work on shells that support Wayland or shells that support X11.

It is no secret that the Mir team is helping with the Wayland support for Flutter and the Wayland support for Lomiri. So there's every reason to expect Flutter apps to work once the Wayland support has been released by both projects.

In seeking ways for developers interested in working on desktop Lomiri to work I've found that adding the UBPorts repository (http://repo.ubports.com/) to 16.04 (xenial) provides a development environment.

We all know that 16.04 support is running out, so I was wondering what the Intel support on the UBports repository is for later series of Ubuntu. I note that there are packages for 18.04 (bionic), but have not investigated how usable they are. Is this something worth trying? Or are there unresolved issues?

And will 20.04 (focal) packages be introduced at some stage?

---

[EDIT]

@mariogrip shared Lomiri desktop running on Manjaro https://twitter.com/Mariogrip/status/1349884746806009856.

Does this mean that Manjaro is a good platform for developers interested in working on Lomiri desktop? Or does the above approach of using Ubuntu + UBPorts archive still make sense?

@jojumaxx said in Browser - Video streaming:

Is that a Linux problem in general or is that just an UT issue?

It is mostly a problem with using graphics hardware that lacks both upstream kernel support and open source drivers. Typically, the drivers included in the original Android OS are problematic to integrate into any other Linux, including UT, because they were compiled against a specific, modified kernel.

@jonius said in Introducing Miroil:

Is the failing tests something I could ignore for now?

Of course. It will get annoying, but if you know you didn't break the code...

You've clearly got enough working to try stuff out.

@jonius said in Introducing Miroil:

the mouse cursor is not visible

That's sort of expected. I disabled the cursor in Mir because QtMir tries to set a zero sized image instead of hiding it. And Mir treats that as an error.

I've not looked at how it works for Lomiri. I suspect it renders its own cursor.

@jonius I don't have VirtualBox to hand to give detailed instructions. But it should work if you enable "the right" graphics options. Not sure what it's called. Something like 'passthrough' or '3D' maybe?

@jonius Not sure why you're seeing different things. Maybe something with the graphics setup in your VM?

Can you run the mir examples? For example:

$ mir-smoke-test-runner
...
I: Smoke testing complete with returncode 0

If that also shows problems, this solution might help (depending on your choice of VM):

https://discourse.ubuntu.com/t/problems-running-electron-app-in-mir-kiosk-on-kvm/16196/6

@jonius I don't have access to my test system just now, but:

pkg-config --cflags miroil

Should return -I/usr/include/miroil (amongst others), and that should be picked up by cmake when run in the QtMir directory.

@c0n57an71n sure. I was about to suggest locking the thread.

@mrlen I didn't say they couldn't make it work. For a company "viable" means something they could make money from.

UBports is a non-profit, and (I strongly suspect) does not pay its employees what they could get elsewhere. That is not viable for a commercial organization.

@mrlen said in Powers that be holding alternatives back | Conspiracy?:

I reckon Canonical stopped Ubuntu Touch because they plain out got told not to continue.
I think that's the reason a lot of companies are not supporting Linux phones.
Kind of like how the oil industry held electric cars back fro 100 years.
That's why it's going to take private funding and grass roots initiatives to get Ubuntu Touch working better.

There is no need for an conspiracy theory.

Markets tend to a small number of dominant players for good reasons and once that happens there are barriers to entry. You can see this is pharmaceuticals, cars, power, etc.

In the case of phones, there needs to be tie-in with regulators, cell service providers, phone manufacturers and app developers.

Canonical have stated that they couldn't make the project viable. There's plenty of evidence that they tried to set up the necessary tie-ins. But, even in markets where there was a clear desire to avoid the dominant supplier, the costs of entry were clearly too high for the expected return.

All of these tie-ins naturally concentrate on the players that make up most of their business to the detriment of unproven newcomers. That's not a conspiracy, that's emergent behaviour and there are lots of examples in economics and elsewhere. The only things that could change this are financial, legal or political incentives.

@emphrath, yes Wayland support is one of the things that came with Mir 1.x. And is even better in later versions of Mir.

At the beginning of 2021

The last year saw various developments around Lomiri, including an alpha of Lomiri on Manjaro.

There is also ongoing work to get Lomiri into Debian and people are trying to build it on Fedora.

My own project, Mir, is important to Lomiri because it provides the low level management of input and output devices, the communication between the desktop environment and apps, portability across different graphics stacks and the basic elements of window management.

However, over the year Mir has been progressing along a related but separate path. This includes several improvements to the graphics driver support that Lomiri needs to work well on Pinephone and improvements to the support of "desktop" applications (including X11) that Lomiri needs for the desktop.

Because Mir needed to drop support for some "legacy" APIs that Lomiri still uses we need to bring Mir and Lomiri together again. (Essentially, Lomiri needs to "move to Mir 2.0".)

The plan

Towards the end of last year I outlined the approach needed to enable Lomiri to use the latest developments in Mir. The plan is essentially to move some code from part of Lomiri (called QtMir) to a new library in Mir (called Miroil).

I followed that post with some notes on how to set up a development environment in which changes to QtMir and Mir can be tested. I also figured out that the best place to make progress is by incrementally moving the code between QtMir and Miroil based on the xenial_-_edge_-_wayland_-_mir18 branch of QtMir and the v1.8.1 version of Mir.

By sticking to Mir 1.x and adding Miroil to that this allows for incremental development before the big jump to Mir 2.x.

The tactics

I've set up a Github project MirOil-for-Lomiri with forks of Mir and QtMir for working on. I'm not going to have time to do much more work on these and would welcome some assistance.

The task at hand is to tidy up the code in QtMir under src/platforms/mirserver/ so that it provides an API to the rest of QtMir suitable for incorporation into Miroil. That means removing from that API any references to Qt or the mirserver or mirclient APIs.

After this the code gets moved to Miroil. There's currently around 8000 lines of code here, so this isn't an enormous project, and because of the way QtMir fits into the Lomiri stack this can be worked on and tested in isolation.

Once this is complete, then I can get Miroil incorporated into a Mir 1.9 release (and into Mir 2.x). That will enable UBports to incorporate just the QtMir changes while using Mir 1.x and migrate to Mir 2.x in due course.

Any volunteers?

I'm happy to help with getting volunteers set up and working, to add them to the github project and provide guidance. But I will be limited to a couple of hours a week in which to do this stuff and won't achieve much by myself.