In the latest blog post from Purism they say they are developing their own Wayland compositor which is madness when there is already a perfect wayland compositor for their needs. I’m talking about Mir (not the server but the new wayland compositor).
Mir compositor is already a well engineered and well developed and maintained Wayland compositor initially created as a Mir server for Unity8, now remade into Wayland compositor.
Have the Purism devs took a look at it? Imho it would fit perfectly PureOS’s needs and usecase.
The definition of madness is to base on a project that Canonical has (not) abandoned (yet).
If they wanted a compositor that supports Wayland + Xorg they could have taken Mutter or kwin.
If they can implement a mostly complete compositor (which is based on existing libs) within a few weeks, what’s the big deal? Clearly, creating and finetuning the shell and apps will be much more time consuming.
I think you misunderstood, Mir compositor is a very actively developed project. It’s driven by Canonical with Ubuntu and UBports foundation. I can’t see your point. This way you are just making one more compositor instead of adopting one that is already being used for the same purpose.
@Caliga I don’t think mir would be worse than the current choise of wlroots, as booth seam to be developed for one major contributor cannonical vs swaywm. Both are open source and could be abounded any time, an would needed to be continued but purism. (But i actually thinks it’s unlikely for both of them)
I had the same thought as @KristijanZic because Mir is developed with touch and mobile in mind from the beginning, i don’t think the same is true for wlroots. So it seams a reasonable idea. The problem i imagine with Mir is the overhead of the Mir server (protocol) part and the overhead of Xmir/XWayland in Mir as purism shoots for an wayland only compositor as i understood. For me the development state, documentation and the resources expected to be committed in future would be the more important aspects to decide.
I actually see much potential in Mir, as Canonical cancel Unity 8 after evaluating which parts of company are profitable. Mir seams to be, as Canonical is actually hiring new Mir developer.
On Mutter and kwin, Al least for Mutter i know its a X server which has gained wayland support an therefore is not a good choice if one aims for a wayland only compositor. kwin might be the same, not sure on this.
So with my little knowledge about the topic of wayland compositors i would say Mir is worth to be considered.
But i’m also confident that the purism team considered this option.
I could imagine some more but totally speculative arguments against Mir.
As purism works closely with gnome towards making gnome a convergent DE it might be a good idea to chose a compositor which might end up as a replacement/next version/alternative for mutter in future gnome releases. I not sure that Mir would fit this criteria.
Also as Cononical will be the major contributor to Mir it will probably be tailored to their need and it might be easier to have a server which purism can easily change to their needs without looking for others. Especially with the time frame of one year, there is not that much time to find compromises with others, i imagine.
wlroots seams easier to me on this problem. But this is also just a feeling without any deeper knowledge.
So while writing i found that i’m probably also be against Mir but for other reasons.
There is no more Mir server, it works on Wayland now as a compositor like Mutter just much more mature expecially for touch interfaces. Canonical is spearheading the development along with UBports foundation. There are plans for Mate to use Mir when they make the swich to Wayland. Afaik there are multiple kiosk OEMs that are using Mir/Wayland as well. Mir is also made with AppArmor security in mind. That’s a pretty big thing I want from a phone security.
If Purism went with Mir/Wayland they would be solving many painpoints and improving their OS greatly instead of creating and supporting tech all by themselves imho.