non-Unity flavours and Mir

[Robert Ancell]

I think most of the points have been covered in this thread but I'll just
emphasise a few points:

- The use of Mir in Ubuntu should have no effect on using any alternative
display systems. Some things will gain Mir backends but everything will
continue to support X and Wayland if the upstreams support it and
developers package and support it in Ubuntu.

- There are a number of different levels of co-existence with Unity/Mir
that are possible:

a) Unity on X and KDE on X - the current case. You can install both and
choose a session from a greeter

b) Unity on XMir and KDE on XMir using Mir as a system compositor [1] -
this is the case you can test from the PPA [2] today. Looks and behaves
much the same as a).

c) Unity on Mir and KDE on XMir using Mir as a system compositor - this is
the case we're working towards. For KDE it will be the same as b).

d) Unity on Mir and KDE on Mir using Mir as a system compositor - IF KWM
was able (have not seen any technical reason this can't be done) and wanted
to create a Mir backend this would work like b) (see discussion later in
this thread).

e) Unity on Mir and KDE on Wayland using Mir as a system compositor - IF
Wayland is able (have not seen any technical reason this can't be done) and
gets a Mir backend this will work IF LightDM support is added like b) (see
below).

f) Unity on Mir using Mir as a system compositor and KDE on Wayland using
Wayland as a system compositor - Would not be able to switch between
sessions. Would either need to switch LightDM configuration or display
managers.

g) Unity on Mir and KDE on Wayland using Wayland as a system compositor -
Would be technically possible but the Mir team has no plans to add a
Wayland backend. Would not be shipped as a default so would not be well
tested by Canonical.

- Canonical will need to support XMir for the foreseeable future. XMir is
just X.org with a Mir backend. This means supporting XMir will mean
supporting most of the case of running X.org in the traditional sense.

- LightDM will continue to support the traditional VT switched X display.
We have extensive regression tests for this case and it is used by a number
of other desktops.

- While Canonical is not going to add Wayland support to LightDM the work
we are doing to support Mir in LightDM is much the same as would be
required to support Wayland in LightDM. Anyone is welcome to implement
this. Note it's not clear to me at the moment how different desktops plan
to use Wayland (no system compositor, shared system compositor, differing
system compositors, same/differing Wayland socket naming conventions). I'll
leave it to Kubuntu/KDE to decide the value in sharing the rest of the
display manager codebase.

--Robert

[1] The "system compositor" is a display server that switches between
running sessions. The purpose of this is to control the graphics during the
whole boot / session lifetime. It replaces handing over between display
servers and VT switching.

[2] https://launchpad.net/~mir-team/+archive/staging

Here's a discussion I half started as part of vUDS.
>
> The switch to Mir in Ubuntu seems pretty risky for the existance of
> Kubuntu, I wonder if other flavours have the same probable problem.
>
> KWin dev has opinions on the subject
> http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/
> From the architecture section on that blog post:
>
>  "Mir’s architecture is centered around Unity. It is difficult to really
>  understand the architecture of Mir as the specification is so full of
>  buzz-words that I don’t understand it [5]. From all I can see and
>  understand Unity Next is a combination of window manager and desktop
>  shell implemented on top of Mir. How exactly this is going to look
>  like I do not know. Anyway it does not fit our design of having
>  desktop shell and window manager separated and we do not know whether
>  Mir would support that. We also do not know whether Mir would allow
>  any other desktop shell except Unity Next, given that this is the main
>  target. Wayland on the other hand is designed to have more than one
>  compositor implementations. Using KWin as a session compositor is an
>  example in the spec."
>
> and on protocol
>
>  "But it gets worse, the protocol between Mir server and Mir clients
>  is defined as not being stable. In fact it’s promised that it will
>  break. That’s a huge problem, I would even call it a showstopper....
>  Given that the protocol may change any time and given that the whole
>  thing is developed for the needs of Unity we have to expect that the
>  server libraries are not binary compatible or that old version of the
>  server libraries cannot talk with the latest client libraries"
>
> Canonical was going to port LightDM to Wayland but now does not plan
> to so someone else would have to do this.  KDE might be interested
> but more likely will switch to SDDM.
>
> For Kubuntu the options are:
> - Use Mir - infeasable as upstream can't support it as described above
> - Use Wayland with packages from Debian and hope we can make those packages
>   live with Mir as best as possible
> - End of Kubuntu
>
> The second options is the one I'm expecting.  It's completely unknown
> how much it means Kubuntu and other flavours will need to maintain X
> and Wayland packages, hopefully not much (it's hardly our speciality)
> and hopefully Debian and Ubuntu Desktop will support it enough.
>
> I don't think there's a public timeline for Mir so we don't know when
> this will hit us, presumably in the next year.
>
> Other flavours I think are this:
> Mythbuntu: not evaluated, hope to do so once NVideo and AMD provide drivers
> Lubuntu: not evaluated, hope to use X and GTK
> ubuntustudio: I've heard both that they use xfce based on xubuntu and
> will follow them, and "aiming for users to choose whatever desktop
> environment they want"
>
> Any other flavours got an opinions?
>
> Are there any misconceptions I have in the above?
>
> Jonathan
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130615/3ca6bec7/attachment-0001.html>