[arch-dev-public] [RFC] Add Wayland/Weston
d at falconindy.com
Fri Feb 8 09:07:26 EST 2013
On Fri, Feb 08, 2013 at 02:55:51PM +0100, Jan de Groot wrote:
> On vr, 2013-02-08 at 10:20 +0100, Thomas Bächler wrote:
> > I appreciate your effort and have no objection against adding Wayland.
> > However, to limit people's enthusiasm about this, I just want to remark
> > that having Wayland installed now is not incredibly useful: Weston is
> > AFAIK the only compositor available at this time, and it is, as you
> > mention, a demo (there was talk of some tiling WM being ported to
> > Wayland, I forgot the name). Also you'll use XWayland most of the time.
> > When Qt5 gets released and Qt4 applications are ported (which will
> > likely happen for all Qt4 applications), there'll be at least many
> > applications that can use Wayland natively. When KDE is ported to Qt5,
> > we'll also get kwin as a more feature-rich Wayland compositor.
> > I didn't read about the GTK situation yet, but I guess GTK3 has Wayland
> > support already.
> This is my main concern for Wayland at this moment. Though it looks cool
> to support new technology and having released versions of Wayland with
> 1.x versioning, I doubt there's much use for it at this moment. Running
> X inside of wayland is a nice feature for apps that aren't ported yet,
> but if you only run apps that aren't ported yet, there's no use for
> Wayland at the moment.
> Anyways, to get everything out of Wayland, this needs:
> - wayland backend in GTK3
> - GL backend in cairo (experimental)
> - EGL/GLES backends in Mesa
> For GTK3 I don't think there's a big issue, it's just a backend
> resulting in some additional files and (optional?) dependencies.
> For Cairo, the GL backend is experimental. Given the fact that upstream
> fails to provide a stable release model for cairo (every released
> version is taken from master, featuring regressions), I wouldn't even
> think about enabling an experimental backend there.
Upstream also claims that applications which don't make use of the GL
backend won't be bothered at all. I don't see the harm in a trial run
> For Mesa, we have to look at how we can implement this without breaking
> existing stuff. I haven't looked much at Mesa recently, so I can't tell
> much about this.
Backends are enabled on a priority basis. As long as we pass
"--with-egl-platforms=x11,drm,wayland" (in that order), we're fine.
More information about the arch-dev-public