On Tue, Jun 18, 2013 at 6:52 AM, Robert Ancell
<robert.ancell@canonical.com> wrote:
>
> On Tue, Jun 18, 2013 at 4:33 PM, Scott Kitterman <ubuntu@kitterman.com>
> wrote:
>>
>> On Monday, June 17, 2013 09:52:49 PM Oliver Ries wrote:
>> > On Fri, Jun 14, 2013 at 11:12 AM, Scott Kitterman
>> <ubuntu@kitterman.com>wrote:
>> Part of the problem is that no one outside Canonical know enough to really
>> have an informed opinion. Here are some immediate questions that come to
>> mind:
>>
>> - How invasive would Mir integration be? Is it isolated enough that it
>> could
>> be integrated upstream based on our testing?
>
>
> It depends on how KWin plans to support non-X display servers.
>
> Options that I know of are:
> a) KWin implements a Wayland display server component from scratch (a lot of
> work)
> b) KWin is a plugin to Weston
> c) KWin uses an existing Wayland display server library (none exist that I
> know of)
>
> In case a) you would need to implement a Mir backend as well as a Wayland
> backend
> In case b) you would need a libmirserver backend in Weston
> In case c) you would have to modify the library or it would need to allow
> backends to be added
>
I took a look at the existing Wayland integration for KWin, cloning with:
git clone git://anongit.kde.org/kde-workspace
From what I could see in the source code, KWin's backend architecture
with respect to rendering boils down to the class
SceneOpenGL (kwin/scene_opengl.h)
which leverages an implementation of OpenGLBackend. OpenGLBackend
abstracts away GL context creation and access to it,
and I can see implementations for GLX and EGL(Wayland) in the source.
To add Mir (note: not XMir) support (in terms of rendering), another
implementation of OpenGLBackend would need to be created that connects
to Mir and bootstraps the EGL/GL setup. For Unity8, which is built on
top of Qt5, we are doing something very similar, although we are
leveraging Qt's platform abstraction layer quite heavily for
abstracting EGL/GL-specific bits'n'pieces (see
https://code.launchpad.net/qtubuntu).
From what I can see in the source code, the current Wayland-backend
creates a fullscreen surface for the session compositor (potentially
talking to the system compositor). Mir supports this, too, and we are
relying on this kind of functionality for XMir.
Is this correct? Or am I missing something?
One thing that I was not able to find is how kwin integrates with
other aspects of the underlying platform/underlying compositor, e.g.:
* Input handling/filtering with the shell/kwin/kde having the first
right to reject
* Application mgmt for being able to define focus strategies, window
placement strategies etc.
* Output mgmt for handling multi-monitor configurations and
transitions between multi-monitor setups
It would be great if someone could give me some direction which code
to look at for these components. I would expect that some sort of
abstraction layer exists that allows kwin/kde to interface with
aforementioned components as X and Wayland are sufficiently different
to justify such an interface. In any case: Mir exposes these
components in terms of source-code interfaces up the stack, and Mir
avoids defining a privileged protocol for those classes of
functionality. Unity 8 consumes Mir by defining an abstraction layer
as in: Unity8 -> Unity8/Mir-Bridge -> Mir, and uses either Mir to
implement the abstraction layer or injects mocks to ease testing of
components like window placement strategies, focus strategies, input
filter chains etc..
Hope this is useful,
Thomas
>> - What's the time line? When , if we follow along with Ubuntu, would we
>> expect to run with XMir instead of X and when would we expect to integrate
>> with MIR natively?
>
>
> We're aiming to be able to preview XMir in 13.10. We're doing the work right
> now to integrate Unity 7 with XMir.
>
>> - When will MIR have a stable API/ABI?
>
>
> The plan is for libmirserver to have a stable API/ABI by the time we release
> Unity 8 (again, around the 13.10 timeframe). We are stabilising libmirclient
> at the moment since it has more consumers than the server API. Though we
> would expect more functionality to be added to both APIs post 13.10.
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
