There are some interesting recent developments on the Mir’s main branch, we’ve been reworking the “graphics platform” APIs to enable a raft of new functionality.
What are the Mir “graphics platform” APIs?
Mir has an abstract idea of what graphics support it needs and provides implementations of that support based on different driver/hardware stacks. Here’s a diagram that provides an overview:
This shows how the platform API relates to the rest of Mir and to the graphics drivers (and hardware).
What needed rework?
There are a number of things that we needed to change:
The note that says “Select the best platform” reflects what the code did and implies that there can be only one platform and that doesn’t reflect the reality of hybrid graphics.
We had also made assumptions that meant that the graphics for output and the graphics for rendering both needed to run on the same graphics card.
By reworking the APIs we have come up with an approach that allows multiple graphics stacks to work at the same time, and for rendering to occur on a different graphics card to the display output.
What have we landed?
Over the last week we landed the major part of this design rework.
As there is still some work to do that deals with corner cases the hybrid graphics part is hidden by a feature flag (defining a MIR_EXPERIMENTAL_HYBRID_GRAPHICS environment variable enables it).
But, even without multiple platforms we can already run compositing on a different card than we render on. This means, for instance that I can use an integrated GPU to render and display via a dock using DisplayLink. (DisplayLink creates a virtual evdi “card” that doesn’t support rendering.)
Discussions of the PR also identified some opportunities for more descriptive naming.
After that, and some more testing, we should be able to remove the feature flag to make hybrid graphics generally available ready for the next Mir release.
There are some Ubuntu flavours which are not uptodate to current Wayland stack, but also there are developers from other Linux companies like RedHat and so which would not prefer to sign CLA for Ubuntu, but those environments also have lack of developers, but there is also a growing list of Ubuntu flavours of which some of them have some disagreement with main GNOME heading, but also a support for not so recent hardware which not only current GNOME droped, but drivers are maybe improving and also maybe Switch to more recent mutter or something will bring benefits to those environments if they accomplish some required standards of GNOME to operate under, MAYBE…
Another problem are phone DE which uses something Linux based(or some Android launchers if Android based), but with terrible linux drivers and also a lack of developers often dropping support for older devices(but Android drivers are also not so easy upgradable often using old kernel and also lack of corporate phone developers)…
If some Canonical projects use Mir, but vendor understanding is that developing a lot of features is killing profitability in them when there are already a lot of existing DE but withouth required Canonical thinking for their projects, something is broken because also hardware vendors(not only phone based) are in deep trouble when dealing with such widespread ecosystem with lack of advanced developers and new are not coming…
If Mir Platform has API to work with, current understanding for a lot of projects is to use FFI to make wide ecosystem, but to manually program such interfaces is Pain in the Ass and there is already a lot of Rust based ecosystem among Flutter one to choose from when Mir Platform API may be in use(and enhance some Canonical projects to make them easy maintainable and developable, but such ecosystem maybe be in more current status and MAYBE in USE if someone be interested)…
Therefore market situation is bad, maybe hardware driver are improving, but its heading is for me in the shadow and clouded and with huge list of bugs and lack of interested skilled developers when there are no more of them…
But important think is, that with huge list of already made applications, need to learn something completely new and also make a complete rewrite of such application make need for such thing with existing linux xorg, flavours, plosh or something a disaster for project like MIR when such developers(often from somewhere, but maybe they are hobbist) may think what to do next…
