Hello gentleman,
Wayland is now in version 1.0.4[1]. I plan to move it to community to offer a first support of the wayland protocol into Archlinux. This will allow toolkit[2][3] packages to smoothly enable wayland support when maintainers wants and let users try this next-to-systemd-troll[4].
After Wayland I would add the demo compositor Weston to our community repositories. To do this we needs to: - enable wayland support into mesa ; - enable wayland support into cairo.
If the both maintainers agreed to add support, we need to find a gentle developper which can move wayland to extra[5].
Cheers,
[1] http://wayland.freedesktop.org/releases.html [2] http://wayland.freedesktop.org/qt5.html [3] http://wayland.freedesktop.org/gtk.html [4] I'm already existed by arch-general be closed again [5] Mesa and cairo are in extra and cannot depends of Wayland in community
[2013-02-08 01:23:30 +0100] Sébastien Luttringer:
Wayland is now in version 1.0.4[1]. I plan to move it to community to offer a first support of the wayland protocol into Archlinux. This will allow toolkit[2][3] packages to smoothly enable wayland support when maintainers wants and let users try this next-to-systemd-troll[4].
After Wayland I would add the demo compositor Weston to our community repositories. To do this we needs to:
- enable wayland support into mesa ;
- enable wayland support into cairo.
I am all for us supporting new technologies when this can be done alongside traditional ones. I trust your judgment that Wayland is ready and see no reason to object its inclusion (so long as you do not propose replacing X with Wayland yet). But that's only my non-expert opinion.
Just one thing:
[4] I'm already existed by arch-general be closed again
I cannot make sense of that sentence...
Hi Sébastien,
Thanks for bringing this up!
On Fri, Feb 8, 2013 at 1:23 AM, Sébastien Luttringer seblu@seblu.net wrote:
If the both maintainers agreed to add support, we need to find a gentle developper which can move wayland to extra[5].
I'd be happy to take wayland to extra when the time comes. Just let me know when you think it is ready. As long as there are no objections from mesa/cairo maintainers that is.
Cheers,
Tom
Am 08.02.2013 01:23, schrieb Sébastien Luttringer:
Hello gentleman,
Wayland is now in version 1.0.4[1]. I plan to move it to community to offer a first support of the wayland protocol into Archlinux. This will allow toolkit[2][3] packages to smoothly enable wayland support when maintainers wants and let users try this next-to-systemd-troll[4].
After Wayland I would add the demo compositor Weston to our community repositories. To do this we needs to:
- enable wayland support into mesa ;
- enable wayland support into cairo.
If the both maintainers agreed to add support, we need to find a gentle developper which can move wayland to extra[5].
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.
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.
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.
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 through [testing].
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.
d
On Feb 8, 2013 2:56 PM, "Jan de Groot" jan@jgc.homeip.net 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.
Thomas and Jan are right, Wayland does not provide much at the moment.
However, I still think it makes a lot of sense to ship it even now, provided it has no negative effects on the non-wayland usecase, and it does not entail too much work. It would at least make life simpler for devs/testers of wayland/weston/kwin and friends.
Cheers,
Tom
On Feb 8, 2013 2:56 PM, "Jan de Groot" jan@jgc.homeip.net 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.
Thomas and Jan are right, Wayland does not provide much at the moment.
However, I still think it makes a lot of sense to ship it even now, provided it has no negative effects on the non-wayland usecase, and it does not entail too much work. It would at least make life simpler for devs/testers of wayland/weston/kwin and friends.
Cheers,
Tom
Am Fri, 8 Feb 2013 09:07:26 -0500 schrieb Dave Reisner d@falconindy.com:
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 through [testing].
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.
d
I've pushed cairo with gl and egl backends to testing. xlib-xcb is now also enabled again that now should be safe to use.
I can't build mesa with --with-egl-platforms=x11,drm,wayland until we have wayland in community or extra to build against.
Package libclc was not found in the pkg-config search path. Perhaps you should add the directory containing `libclc.pc' to the PKG_CONFIG_PATH environment variable No package 'libclc' found Package libclc was not found in the pkg-config search path. Perhaps you should add the directory containing `libclc.pc' to the PKG_CONFIG_PATH environment variable No package 'libclc' found checking for XCB_DRI2... yes checking for xcb_dri2_connect_alignment_pad in -lxcb-dri2... yes checking for WAYLAND... no configure: error: Package requirements (wayland-client >= 1.0.2 wayland-server >= 1.0.2) were not met:
No package 'wayland-client' found No package 'wayland-server' found
-Andy
Now that Wayland has landed in Community I can build Mesa with support for Wayland. This leads to a new dependency in libegl:
libegl E: Dependency wayland detected and not included (libraries ['usr/lib/libwayland-server.so.0', 'usr/lib/libwayland-client.so.0'] needed in files ['usr/lib/egl/egl_gallium.so','usr/lib/libEGL.so.1.0.0'])
Since cairo will also depend on that libegl then every system will pull in Wayland. Is this really needed? If we can't build it in a different way we directly need to move Wayland to extra.
-Andy
On 09/02/13 22:43, Andreas Radke wrote:
Am Fri, 8 Feb 2013 09:07:26 -0500 schrieb Dave Reisner d@falconindy.com:
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 through [testing].
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.
d
I've pushed cairo with gl and egl backends to testing. xlib-xcb is now also enabled again that now should be safe to use.
I don't know why, but this causes transmission-gtk to hit 100% CPU usage on my system.
Allan
Am Sat, 9 Feb 2013 17:35:27 +0100 schrieb Andreas Radke andyrtr@archlinux.org:
Since cairo will also depend on that libegl then every system will pull in Wayland. Is this really needed? If we can't build it in a different way we directly need to move Wayland to extra.
-Andy
Bump.
If we agree that we want to start to support Wayland in Arch we need to move Wayland libs to the extra repo. Then I can build Mesa making use of it in libegl. This shouldn't harm anything else and wayland libs are a pretty small pkg (when we drop the static libs).
So who's going to move it to extra and wants to maintain it there? I could build it but will not use it myself anytime soon.
-Andy
On Tue, Feb 12, 2013 at 5:42 PM, Andreas Radke andyrtr@archlinux.org wrote:
Am Sat, 9 Feb 2013 17:35:27 +0100 schrieb Andreas Radke andyrtr@archlinux.org:
Since cairo will also depend on that libegl then every system will pull in Wayland. Is this really needed? If we can't build it in a different way we directly need to move Wayland to extra.
-Andy
Bump.
If we agree that we want to start to support Wayland in Arch we need to move Wayland libs to the extra repo. Then I can build Mesa making use of it in libegl. This shouldn't harm anything else and wayland libs are a pretty small pkg (when we drop the static libs).
So who's going to move it to extra and wants to maintain it there? I could build it but will not use it myself anytime soon.
I'll be happy to maintain Wayland, so I'll take it over and move it to [extra].
-t
On Fri, Feb 8, 2013 at 1:23 AM, Sébastien Luttringer seblu@seblu.net wrote:
Hello gentleman,
Wayland is now in version 1.0.4[1]. I plan to move it to community to offer a first support of the wayland protocol into Archlinux. This will allow toolkit[2][3] packages to smoothly enable wayland support when maintainers wants and let users try this next-to-systemd-troll[4].
After Wayland I would add the demo compositor Weston to our community repositories. To do this we needs to:
- enable wayland support into mesa ;
- enable wayland support into cairo.
If the both maintainers agreed to add support, we need to find a gentle developper which can move wayland to extra[5].
Some news from the front: - Wayland is in extra, thanks to Tom G. for moving it. - Mesa and cairo have their wayland backend enabled in testing, thanks to Andreas R. - Weston is in community-testing. You can now play with the first wayland compositor/windows-manager.
Cheers,
On Thu, Feb 14, 2013 at 12:38 AM, Sébastien Luttringer seblu@seblu.net wrote:
On Fri, Feb 8, 2013 at 1:23 AM, Sébastien Luttringer seblu@seblu.net wrote:
...
Some news from the front:
- Wayland is in extra, thanks to Tom G. for moving it.
- Mesa and cairo have their wayland backend enabled in testing, thanks
to Andreas R.
- Weston is in community-testing. You can now play with the first
wayland compositor/windows-manager.
Hello,
Mesa and cairo with wayland support are now in extra. Weston has reach community today. gtk3 with wayland support is still in testing.
Support of wayland in qt require qt5 module qtwayland[1] which is still in beta state. I will wait first release before inclusion.
Cheers,
[1] http://qt-project.org/wiki/QtWayland
arch-dev-public@lists.archlinux.org