Wayland plasnning meeting notes

[Aleix Pol]

On Mon, Jul 21, 2014 at 3:06 PM, Marco Martin <notmart at gmail.com> wrote:

> This is hopefully a synopsis of what has been said in the wayland planning
> meeting.
>
> If I got something wrong, please reply in the thread the correction ;)
>
>
> mgraesslin:
> * will give a talk on the current state at akademy
> * it probably does not make any sense to start working on other parts
> before
> at least the basics are ready in KWin
> * Weston as a development target will not give us much to work on Plasma
>
> plfiorini:
> * would like to write the plasmashell and test it in another compositor
> (not
> weston) at the same time you can wrok on kwin
> * is pushing for QtWayland release together with Qt 4.4, let's see if that
> happens
>
> Sho asks if couldn't we write a kwindowsystem backend that speaks
> xdg_shell to
> the compositor?
>
> Mgraesslin:
> wouldn't help, because xdg_shell is for taking with other windows - no
> need to
> have that in KWindowSystem as QtWayland needs to speak it.
> This is an implementation detail, and should not be public api.
> The idea is to get the Wayland backend into KWin and map all relevant
> information to an X11 window. Wayland windows would still be valid X11
> windows. Libtaskmanager would then still work and will make possible a
> step by
> step transition, and would allow to reuse a lot of current code in KWin.
>
> Also part of the same plan, libtaskmanager should be plugin based.  If we
> go
> that road we could implement the required plugin in libtaskmanager first
> without having to go all public directly.
>
> Discussion then gone a bit over Dialog: it needs to position itself with
> global coordinates and know the screen geometry. some changes in wayland,
> or
> the plasmashell->kwin protocol will need to allow global coordinates for
> windows.
>
> plfiorini: seems decision is leaning towards not having a system
> compositor.
> mgraesslin: kwin needs one:for 2 reasons: we can't have hardware specific
> code
> (like rendering on raspberry codepath) and kwin should not be privileged.
> So
> KWin may use the fullscreen shell of Weston as system compositor, different
> from the old concept of system compositor.
>
> mgraesslin: the wayland part of KWin will be quite standalone and
> isolated, so
> can be used as an integrated Wayland server, usable for integration tests
>
> Plasmashell relies heavily on KScreen that may pose a problem: it will need
> either to have KScreen supporting Wayland internally or to be ported again
> back to QScreen, needing QScreen to be fixed on both X11 and Wayland.
>
> Shadows should still have a protocol similar to now, to be painted by kwin
> and
> not by the window. In the same way output only windows should have a
> protocol
> for that instead of playing with masks, the general direction is to have
> protocols shell->kwin instead of windows working around problems.
>
> plfiorini says he may have a draft of the palsmashell->kwin protocol spec
> open
> for comment around middle of August.
>

Regarding KScreen, it really should be ported, at the moment QScreen
doesn't provide the information we need. I introduced one of the big
missings for 5.4, which was screenRemoved, but we'll still need at least a
primaryChanged signal.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140721/a554c5ce/attachment.html>