Debian GNU/Linux

Enable wayland backend

Reported by Darxus on 2012-03-13
430
This bug affects 90 people
Affects Status Importance Assigned to Milestone
gtk+3.0 (Debian)
New
Unknown
gtk+3.0 (Ubuntu)
Wishlist
Unassigned
Quantal
Wishlist
Unassigned
Raring
Wishlist
Iain Lane

Bug Description

Add --enable-wayland-backend to build flags. I believe this is all that's necessary for wayland to work with the existing Precise gtk packages.

Wayland has one released version, 0.85, which is in the precise archives: https://launchpad.net/ubuntu/+source/wayland/

I'm told gtk 3.4 is (and will remain) compatable with it. Since gtk 3.4 is apparently already packaged for Precise, all that remains to be able to use some gtk applications via wayland is this build flag.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gtk+3.0 (Ubuntu):
status: New → Confirmed
Mathias Hasselmann (hasselmm) wrote :

how about setting up a PPA to verify this theory?

Sven Romeike (lun4tic) wrote :

I'd like to see Wayland in action cause X is ancient even with the newly written stuff and composite extensions.

Mathias Hasselmann (hasselmm) wrote :

ok, it's more work than just passing --enable-wayland-backend:

    configure: error: Package requirements ( cairo-gl) were not met:

    No package 'cairo-gl' found

Mathias Hasselmann (hasselmm) wrote :

ok, next problem: for whatever reason GtkSocket and GtkPlug get lost if you build with --enable-wayland

Darxus (darxus) wrote :

It looks like there is a serious problem with enabling cairo-gl, related to the nvidia proprietary drivers: Bug #725434 .
The cairo packager has closed a request to enable cairo-gl as wontfix due to this problem: Bug #804379.

Mathias Hasselmann (hasselmm) wrote :

darxus - uch, that hurts!

Rob Clark (rob-ti) wrote :

I don't suppose enabling cairo-gles2 instead gets around the nv bug? Wayland will work happily w/ egl+gles2+cairo-gles2 combo..

Darxus (darxus) wrote :

Rob: My understanding is that for the wayland sample clients (weston), cairo-gl is optional, and for the wayland backend of gtk it is required.

In the wayland build instructions for cairo-gl:
"The Wayland clients can render using cairo-gl, but fall back to software when cairo-gl is not available. "

Darxus (darxus) wrote :

Matthias: So what was necessary, just enabling wayland in gtk, and enabling cairo-gl in cairo?

Mathias Hasselmann (hasselmm) wrote :

darxus, plus a small patch for gtk: the wayland backend exported some private symbol by accident. the fix is upstreamed already.
rob, it seems we'll need cairo-gl. but there also seems to be some chances, that the cairo-gl vs. nvidia issue was a TLS bug in libc 2.13 (at least that's what the gentoo guys claim). precise has libc 2.15.

Darxus (darxus) wrote :

https://launchpad.net/~ricotz/+archive/staging/+packages
In this repo, the gtk+ packages have the wayland backend enabled, and the cairo packages have cairo-gl enabled.

Darxus (darxus) wrote :

Better link for that ppa, including the warning that these packages are risky to play with: https://launchpad.net/~ricotz/+archive/staging/

Darxus (darxus) wrote :

I did some testing of the previously mentioned ppa:ricotz/staging under Precise.
It is not at all usable. Due, I believe, to problems in gtk+, not the packaging. ricotz tells me that enabling both the wayland and x11 backends for gtk+ is just broken.

Without adding a ~/.xsessionrc, X does not start. After adding ~/.xsessionrc containing

export CLUTTER_BACKEND=x11
export GDK_BACKEND=x11

X didn't start on startup, but did start when I ran startx. Didn't do much other than notify me that nautilus crashed and ask me if I wanted to report it.

I tried running gnome-terminal from the console. It gave me the expected error that DISPLAY wasn't set, so I set it (export DISPLAY=:0). Then it gave a XDG_RUNTIME_DIR not set warning, which is a wayland thing. So I set the above two BACKEND variables in that shell, and tried again, and gnome-terminal gave me:

Gdk-CRITICAL **: gdk_wayland_device_get_selection_type_atoms_libgtk_only: assertion `GDK_IS_DEVICE_CORE (gdk_device)' failed

Before doing any of this, I recommend: apt-get install ppa-purge
Also, if you end up at a text console that isn't responding to your keyboard, do alt-sysrq-r.
And if you need to switch between nvidia proprietary and nouveau drivers from the console because X won't start, you can use jockey-text, although it looks like it doesn't update /etc/X11/xorg.conf, which is necessary, so have working backup copies of that file.
You should also know about rebooting via alt-sysrq reisub, although I haven't had to do that in this process.

What I did was, freshly install Precise, then:
sudo apt-get update && apt-get dist-upgrade
sudo add-apt-repository ppa:ricotz/staging
sudo apt-get install libcairo2 libcairo-gobject2 gir1.2-gtk-3.0 libgail-3-0 libgtk-3-0 libgtk-3-bin libgtk3-common

Then to revert: sudo ppa-purge ppa:ricotz/staging

I also came across a weird bug where a third line containing "ain" was showing up in /etc/apt/sources.list.d/ricotz-staging-precise.list, probably an add-apt-repository bug. Just edit that file and delete that line.

Darxus (darxus) wrote :

Bug #725434 resulted in cairo-gl being disabled for causing "a 300% increase in memory use at login as compared to previously". Comment #12 mentioned a theory that this memory problem was actually in a version of libc nolonger used in Precise. I just tested the difference between memory use of some applications I expect to be using gtk+ at startup in Precise with and without cairo-gl enable. I installed cairo-gl via:

sudo add-apt-repository ppa:ricotz/staging
sudo apt-get install libcairo2 libcairo-gobject2

While total real + swap = virtual memory is about the same, a number of applications do have roughly 300% of the memory usage with cairo-gl enabled as they do with it disabled. So it looks like we still have the cairo-gl + Nvidia proprietary driver memory problem?

                  cairo-gl disabled enabled
                                    VIRT RES VIRT RES RES %
compiz
indicator-sound 517m 6868 649m 24m
compiz 956m 120m 1043m 120m 100%
nautilus 732m 28m 789m 45m 161%
indicator-print 476m 9.9m 463m 28m 283%
indicator-sessi 588m 6000 647m 24m
indicator-print 476m 9.9m 463m 28m 283%
indicator-messa 575m 6364 418m 23m
indicator-appli 411m 4744 608m 22m
indicator-datet 480m 7344 675m 25m

Darxus (darxus) wrote :
Darxus (darxus) wrote :
Darxus (darxus) wrote :

Enabling the wayland and x11 backends of gtk+ simultaneously appears to be unusable: https://bugzilla.gnome.org/show_bug.cgi?id=672361

Related to the cairo-gl vs. Nvidia proprietary problem:
A) Get cairo-gl to only load libGL when an application requests it: https://bugs.freedesktop.org/show_bug.cgi?id=47480
B) Get the Nvidia proprietary driver to reduce memory consumption. I haven't touched this one. All I have found is linux-bugs at nvidia.com mentioned on http://www.nvidia.com/object/linux_display_ia32_169.09.html
C) Remove the cairo-gl dependency from the wayland backend of GTK+: https://bugs.freedesktop.org/show_bug.cgi?id=47480
D) Add support for versioned provides to the Debian packaging system: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7330
   This bug is 15 years old.

My post to the wayland list about this: http://lists.freedesktop.org/archives/wayland-devel/2012-March/002650.html

> Get the Nvidia proprietary driver to reduce memory consumption. I haven't touched this one.
Tech. support here: http://nvidia.custhelp.com/app/ask

Darxus (darxus) wrote :

Rob Bradford provided a patch to make gtk built with both wayland and x11 backends usable: https://bugzilla.gnome.org/show_bug.cgi?id=672358#c8 (by disabling the wayland clipboard when both are built).

When GTK+ 3.4 is released next week it will be merged into Ubuntu Precise. But it appears to have been decided that this patch will not be included until GTK+ 3.4.1, and Ubuntu won't cherry pick it because the wayland backend isn't being enabled anyway (because of the remaining Nvidia propreitary problem and the fact that it's way past feature freeze).

#ubuntu-desktop on irc.freenode.net appears to be where ubuntu gtk+ decisions are made.

A phoronix comment explained that the part of the Nvidia problem is "...nVidia builds their drivers with position dependant code, which is slightly faster but can not be shared between different programs (so it gets duplicated for each program running that uses GTK+)" - http://phoronix.com/forums/showthread.php?69536-Whoops-There-s-A-Big-Problem-For-Wayland-GTK&p=254956#post254956

Darxus (darxus) wrote :

Now that I know that the Nvidia problem is due to Nvidia choosing to build their driver in a way that doesn't allow shared memory...

"While not a big deal on machines with 2+GB ram on older machines with 1 GB it does represent a bit of an issue." - Bug #725434

It's seeming more reasonable to go ahead and enable cairo-gl and just recommend that people use Nouveau instead of the proprietary drivers on machines with less than 2gb ram. (I say this as I've been using Nouveau on a machine with 8gb ram.)

Eric Appleman (erappleman) wrote :

I'd ask on nvnews for Nvidia insight.

A lot of their Linux staff post there.

http://www.nvnews.net/vbulletin/forumdisplay.php?f=14

Darxus (darxus) wrote :

Eric: Go for it.

"NVidia knows about this and will not do anything." - http://lists.freedesktop.org/archives/wayland-devel/2012-March/002652.html

Darxus (darxus) wrote :

Nvidia proposed a solution to the Nvidia proprietary + cairo-gl memory problem:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/967149

Opened as bug #967149.

Eric: Did you cause this? If so, thanks.

I did see Eric's thread on the nvnews.net forums, but I'd been keeping an eye on this for a while now.

Darxus (darxus) wrote :

Pierre: Thank you.

Changed in gtk+3.0 (Ubuntu):
importance: Undecided → Wishlist
Darxus (darxus) on 2012-04-09
tags: added: wayland
Darxus (darxus) wrote :

Found another problem, Ubuntu's modifications to GTK+ are incompatible with Wayland, bug #984914.

I've been tagging things that affect wayland with "wayland": https://bugs.launchpad.net/ubuntu/+bugs?field.tag=wayland

I've been trying to build GTK+ packages with the Wayland backend enabled: http://lists.freedesktop.org/archives/wayland-devel/2012-April/003008.html
Builds and works locally, won't build in my PPA. If you have any idea what build dependencies I'm missing please let me know.

Darxus (darxus) wrote :

Got GTK packages working with the Wayland backend enabled: https://launchpad.net/~darxus/+archive/wayland-gtk
Thanks to a workaround from seb128 - you just need to "export LIBOVERLAY_SCROLLBAR=0".

More info here: http://lists.freedesktop.org/archives/wayland-devel/2012-April/003009.html

Thanks to Rob Bradford for the patches that made this possible.

Darxus (darxus) wrote :

This is a debdiff from the gtk package currently in precise (3.4.1-0ubuntu1) to my ppa which has the wayland backend enabled (3.4.1-0ubuntu1+wayland2 in https://launchpad.net/~darxus/+archive/wayland-gtk ). What is needed to get this in quantal?

The changes are:
1) 1 patch to default to X11 output before Wayland (from krh) which fixes some X breakage, from gtk master.
2) 7 patches to remove dependency on cairo-gl (from robster), from gtk master.
3) Add --enable-wayland-backend and --enable-x11-backend to DEB_CONFIGURE_EXTRA_FLAGS.
4) Add libwayland-dev and libxkbcommon-dev to build dependencies.

Since these patches are already in gtk master, and there will be another stable release from current gtk master before Quantal is released, this won't be a delta from upstream requiring long term maintenance. (gtk release 3.6.0 on 2012-09-26 - https://live.gnome.org/ThreePointFive )

The attachment "gtk+3.0_3.4.1-0ubuntu1.dsc-gtk+3.0_3.4.1-0ubuntu1+wayland2.dsc.debdiff" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Alan Bell (alanbell) wrote :

I have successfully tested the code in darxus's ppa and it works great for the regular desktop and also allows GTK clients to run in the weston compositor. Would be rather smashing to get this in to Quantal from the start.

Alan Bell (alanbell) wrote :

I should say I am testing on 12.04 with unity3d and unity 2d on a laptop with intel graphics.

Krad Radio (kradradio) wrote :

Worked for me. (But I'm an expert and never have computer problems :D)

Sebastien Bacher (seb128) wrote :

Unsucribing sponsors that's not a patch suitable for a stable update

Darxus (darxus) wrote :

Sebastien: But I believe it's entirely appropriate for Quantal. Why hasn't it been applied to that yet? It's been almost two months.

Sebastien Bacher (seb128) wrote :

Quantal work has not started for that long but gtk 3.5 is being prepared for upload (in fact it's ready for a bit but some theming changes mean that unico needs to be updated, the current version segfaults with the new gtk), it should go in quantal next week (this week changes are reduced for alpha1), then we can apply the changes to start building with wayland. Is there any patch needed which is not in gtk 3.5.2?

Darxus (darxus) wrote :

Great, thanks. Since all necessary patches were in master by 2012-04-18 I'd expect them all to be in 3.5.2.

Darxus (darxus) wrote :

It looks like you're now producing Quantal specific gtk packages, and wayland is still not enabled ( http://archive.ubuntu.com/ubuntu/pool/main/g/gtk+3.0/gtk+3.0_3.5.10-0ubuntu1.debian.tar.gz )

Can you enable wayland in the quantal gtk package now?

Darxus (darxus) wrote :

Wayland and Weston 0.95 packages are in Quantal.

I just noticed feature freeze was two days ago. I opened this bug five months ago, and created a ppa and debdiff demosntrating the change three months ago. Please enable wayland in the gtk packages for quantal.

Changed in gtk+3.0 (Debian):
status: Unknown → New
Darxus (darxus) wrote :

GTK+ PPA with --enable-wayland-backend for Quantal:
https://launchpad.net/~darxus/+archive/wayland-gtk-quantal

As expected, just requires adding --enable-wayland backend.
And --enable-x11-backend (because if you do wayland and not x11 it disables x11).
And less expected, there's an apparent bug in GTK requiring adding the additional symbols to gdk/gdk.symbols: https://bugzilla.gnome.org/show_bug.cgi?id=682709

Fred (eldmannen+launchpad) wrote :

I'm running GTK with --enable-wayland from Darxus PPA mentioned above.

It seem to work. :)

I would love to see GTK compiled with --enable-wayland on Quantal. :)

omichalek (omichalek) wrote :

GTK3 from the PPA it works for me too, is there any reason not to go with it?

Jeremy Bicha (jbicha) on 2012-08-29
Changed in gtk+3.0 (Ubuntu Quantal):
status: Confirmed → Won't Fix
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Jeremy Bicha (jbicha) wrote :

It's still unclear whether enabling wayland support would cause regressions in GTK. Wayland support isn't a priority for 12.10, and even Fedora doesn't enable the Wayland backend yet. It's after feature freeze so the cost/benefit analysis makes a feature freeze exception being granted for this unlikely.

Seb said that he'd like to check with Matthias Clasen first to see what he thinks about enabling this option, perhaps for 13.04.

Sebastien Bacher (seb128) wrote :

That cross-fired over IRC upstream discussion, so to summarize my position:

- we (desktop team) have enough to work on to keep busy without that
- it seems no other distribution enable wayland (which means in reality it gets little testing, they might also have reasons to not enable it)
- wayland is not a priority for us at the moment
- we don't really have a gtk maintainer
- we are not wanting to deal with issues under wayland and enabling it might push people to consider we support it and open ubuntu bugs against random app which doesn't work under wayland ... we are not ready nor wanting to deal with those at the moment
- we don't know what issue enabling the backend could create on GTK (as the bug history show there has been issues in the past)

So yeah, would be nice to turn on but the cost,benefit seems in our disfavor so far...

Sebastien Bacher (seb128) wrote :

@Darxus: thanks for your work on that btw, is there any reason you want it in the main archive? It seems like a testing ppa is the right place for that at the moment...

Darxus (darxus) wrote :

Sebastien: Because all the chicken and egg problems with wayland are annoying, and this is a step we can take in the right direction. And it's a huge part of the usability of wayland - which is expected to be used by clients primarily through GTK+ and Qt. And people were testing it and saying it didn't break things three months ago.

You mention a history of enabling this backend causing problems. I acknowledge there were a couple major regressions, but they were fixed before I even created the precise ppa. By defaulting to X over Wayland (as suggested / written by krh), and disabling the wayland clipboard when the X backend was also built. So yes, regressions are possible, but do not seem to have occurred for some time.

I was kind of frothing at the suggestion that ubuntu shouldn't enable this just because other distros haven't, until I realized the head gtk maintainer, Matthias Clasen, is employed by Red Hat, so that makes a little sense. Although I don't think they have wayland 0.95 packaged yet, so it's... more steps for them to achieve. And everybody standing around waiting for somebody else to do something is annoying.

It's unfortunate that we're past feature freeze. But we weren't five months ago when I opened this bug, and we weren't three months ago when I created the precise ppa and people said it didn't break things. And unlike last release, this isn't an LTS release. And we still have two beta releases to go before final.

Thanks for asking :)

Darxus (darxus) wrote :

What needs testing (by you):
We need to verify that enabling the wayland backend does not cause regressions (things breaking that weren't broken) with X. Verifying that things work with wayland is not really relevant to this bug.

<xclaesse> for now, the question is more: does turning wayland backend on affect the x11 backend
<mclasen> xclaesse: as I said, there's some backend-specific parts in libgtk where there is potential for problems
<mclasen> but it is fairly limited: dnd, clipboard, xembed, tray icons
<mclasen> of course, there's plenty of potential for individual apps to refuse to work on wayland
<mclasen> but I guess thats not a concern at this point

So, installing the packages in this ppa, rebooting, and testing dnd (drag and drop), clipboard (copy and paste), xembed, and tray icons, is what is currently most useful for this bug:
https://launchpad.net/~darxus/+archive/wayland-gtk-quantal

Fred (eldmannen+launchpad) wrote :

I have still not experienced any X problems with the Wayland-enabled GTK.

Darxus (darxus) wrote :

Updated PPA from 3.5.12-0ubuntu3+wayland0 to 3.5.16-0ubuntu1+wayland0.

Darxus (darxus) wrote :

Debdiff from gtk+3.0_3.5.16-0ubuntu1 to gtk+3.0_3.5.16-0ubuntu1+wayland0. Nothing new from last time, except I specified v0.95 or newer for the libwayland build dependency.

Darxus (darxus) wrote :

Updated PPA to gtk+3.0 - 3.5.18-0ubuntu1. I see there's a 3.5.18-0ubuntu2 here:
https://launchpad.net/ubuntu/quantal/+source/gtk+3.0/3.5.18-0ubuntu2
But not sure how to tell if I should use that or just wait for it to get to the archives.

Updating sure is a lot faster when just applying the debdiff instead of going through the whole process again. Only chunk that failed was the changelog.

Iain Lane (laney) wrote :

I propose we revisit this at the start of R-cycle. I've subscribed to this bug, so feel free to ping if I forget to do that then.

Darxus (darxus) wrote :

Iain: Great, thanks. So I should remind you around when Quantal is released?

Updated PPA for 3.5.18-0ubuntu2: https://launchpad.net/~darxus/+archive/wayland-gtk-quantal

Darxus (darxus) wrote :

Updated ppa for gtk+3.0_3.5.18-0ubuntu3. debian/patches/series didn't apply cleanly from previous debdiff, reason and solution were obvious.

CSRedRat (csredrat) wrote :

Enabled 1.0.2?

Iain Lane (laney) wrote :

For Raring, we need to cherry pick e5b88f1bdd570e9f411a8be41199adceb950c61c to work with wayland 1.0's API. I'm doing a test build of this now and will upload to a PPA if it succeeds. I'll then run this GTK for a bit and if there's no problems I will upload to raring

Iain Lane (laney) wrote :

Oh, I'm sorry but this isn't going to be possible.

Extra backends get compiled right into GDK. This means that libgtk-3-0 gets a dependency on wayland and libxkbcommon and there's no way to split it out. It would always have been difficult to get wayland into main as a build dep of GTK, but it really won't be possible to have GTK+ depending on wayland.

Sorry. I suggest you keep on going with a PPA if folks want to use GTK+3 in Ubuntu with its wayland backend.

Changed in gtk+3.0 (Ubuntu Raring):
status: Confirmed → Won't Fix
Fred (eldmannen+launchpad) wrote :

Then let it have a dependency on wayland and libxkbcommon.
It will have to sooner or later anyway. Just a matter of time.

Fred (eldmannen+launchpad) wrote :

You're merely postponing the inevitable.

Darxus (darxus) wrote :

Fred: I think you misunderstand.

I don't think Iain is saying this can't be fixed. Somebody please correct me if I'm wrong, but it sounds to me like the solution which would make Iain happy, and not cause any problems for anybody else, would be if GTK+ built its Wayland backend into a separate dynamically loadable library, and loaded it at run time. So that a GTK+ package could be installed and run (at all, under X), without the absolute necessity of installing a Wayland package just to get GTK+ to run (at all, under X).

Iain, can you confirm I understand this, so I can at least open a bug against GTK+ requesting it? Is there anything else that would be needed? This has been a pretty frustrating process. Thanks for trying.

Luke (lukekuhn) wrote :

For gtk+3.0 to depend on wayland in the Ubuntu repos would require that none of the proprietary drivers force the removal of wayland. I suppose this could be done in such a way that wayland would be installed but broken with the proprietary drivers installed, assuming the session and all programs fall back to X without any issues.

This concern goes out the window if either both Nvidia and AMD start supporting Wayland in their prop drivers, or (my preferred scenario) the open source drivers catch up. Radeon is closing fast on Catalyst, Nvidia's lesser cooperation compared to AMD has meant the nouveau team has to fight tooth and nail to get performance. I'd love to see Wayland force both AMD and Nvidia to throw up their hands and release all the non-"digital rights management" related commands and algorithms for their hardware so they would no longer have to write proprietary Linux drivers at all.

Hey,

On Mon, Dec 17, 2012 at 06:17:37PM -0000, Darxus wrote:
> Fred: I think you misunderstand.
>
> I don't think Iain is saying this can't be fixed. Somebody please
> correct me if I'm wrong, but it sounds to me like the solution which
> would make Iain happy, and not cause any problems for anybody else,
> would be if GTK+ built its Wayland backend into a separate dynamically
> loadable library, and loaded it at run time. So that a GTK+ package
> could be installed and run (at all, under X), without the absolute
> necessity of installing a Wayland package just to get GTK+ to run (at
> all, under X).
>
> Iain, can you confirm I understand this, so I can at least open a bug
> against GTK+ requesting it? Is there anything else that would be
> needed? This has been a pretty frustrating process. Thanks for trying.

That is right. I'm sorry that I didn't know the architecture of the
backends in advance so that I could have told you sooner. You could open
a bug requesting this, but I'm not sure how fundamental the
architectural decisions go — it might be best to ask on gtk-devel-list.
The problem is that GTK+ is such a core library that it really is out of
the question to have it pull in wayland when we're not using it by
default. I hope you understand this. I looked into it today in good
faith attempting to see if it would be possible to enable it per this
request.

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Darxus (darxus) wrote :
Darxus (darxus) wrote :

The GTK+ folks closed the above bug, to split the wayland backend into a dynamically loadable library, "wontfix" saying "No".

Darxus (darxus) wrote :

Iain, could you say what exactly the reasons are for not wanting the gtk package to depend on a wayland package?

I posted about this problem here: http://lists.freedesktop.org/archives/wayland-devel/2013-January/006888.html
A couple people have said what they think the reasons are in replies. It would be good to be sure, to help figure out a solution.

It might help to say what the reason is for having wayland conflict with proprietary drivers. I recognize weston (the reference wayland implementation) won't run on those drivers. But I'm not sure why its package would conflict with them (and I'm having difficulty checking what the conflicts actually are). But you could have the weston package conflict with those proprietary drivers, but have libwayland installable, and then be able to run gtk with a dependency on libwayland?

Darxus (darxus) wrote :

Iain, are you aware the mesa packages already depend on libwayland0? Shouldn't that make it okay for gtk to depend on libwayland0?

Benjamin Drung (bdrung) wrote :

libegl1-mesa depends on libwayland0 in raring. Purging libwayland0 on raring would purge empathy and totem. Therefore we will have libwayland0 installed on the installation media. I see no reason to avoid letting gtk depend on libwayland0, but allow libegl1-mesa to depend on it.

I will enable the wayland backend and upload it to raring if there is no problem caused by this change and no new reason against it is provided.

Iain Lane (laney) wrote :

On Tue, Jan 08, 2013 at 11:10:32PM -0000, Benjamin Drung wrote:
> libegl1-mesa depends on libwayland0 in raring. Purging libwayland0 on
> raring would purge empathy and totem. Therefore we will have libwayland0
> installed on the installation media. I see no reason to avoid letting
> gtk depend on libwayland0, but allow libegl1-mesa to depend on it.
>
> I will enable the wayland backend and upload it to raring if there is no
> problem caused by this change and no new reason against it is provided.

You're right - I'm not sure if it's entirely necessary but cogl got a
dependency on libegl1-mesa in 1.12.0-1.

So libwayland0 is on media already. So I do think you can go ahead and
enable the wayland backend if you have the patches prepared already, or
I can do it tomorrow assuming I still have the packages I made while
originally evaluating the fix for this bug.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Darxus (darxus) wrote :

Yay.

In case anybody else was trying to look up how libwayland0 ended up in main: https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/810217
(MIR = Main Inclusion Request)

Darxus (darxus) wrote :

Somebody want to un-close this bug for raring? Won't let me.

Sebastien Bacher (seb128) wrote :

> Somebody want to un-close this bug for raring? Won't let me.

done

Changed in gtk+3.0 (Ubuntu Raring):
status: Won't Fix → Triaged
Iain Lane (laney) wrote :

I looked again. See the wdiff of the Depends line after enabling wayland

Control files of package libgtk-3-0: lines which differ (wdiff format)
----------------------------------------------------------------------
Depends: libgtk-3-common (= [-3.6.2-0ubuntu1),-] {+3.6.2-0ubuntu2),+} libatk-bridge2.0-0 (>= 2.5.3), libatk1.0-0 (>= 2.2.0), libc6 (>= 2.14), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.10.0), libcolord1 (>= 0.1.10), libcups2 (>= 1.6.0-1), libfontconfig1 (>= 2.9.0), libgdk-pixbuf2.0-0 (>= 2.25.2), libglib2.0-0 (>= 2.33.14), libpango1.0-0 (>= 1.30.0), {+libwayland0,+} libx11-6 (>= 2:1.4.99.1), libxcomposite1 (>= 1:0.3-1), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxi6 (>= 2:1.2.99.4), libxinerama1, {+libxkbcommon0 (= 0.1.0~2-0ubuntu1),+} libxrandr2 (>= 2:1.2.99.3), shared-mime-info, at-spi2-core

We gain libwayland0 and libxkbcommon0.

libxkbcommon0 is in universe. Benjamin, do you want to talk to ubuntu-x about whether main inclusion would be feasible? Note that its description says this:

Description-en: library interface to the XKB compiler - shared library
 libxkbcommon aims at replacing xkbcomp, the XKB compiler.
 .
 UNSUPPORTED. This is an experimental library, and its ABI/API is likely to change
 on a regular fashion before it stabilizes, depending on XServer's and
 Wayland's needs in particular.
 .
 More information about X.Org can be found at:
 <URL:http://www.X.org>

Darxus (darxus) wrote :

I think that libxkbcommon0 description is out of date, probably written before there was a release, when the package was built from a git repo.

Iain Lane (laney) wrote :

diff

Iain Lane (laney) wrote :

git repo> Yeah, that's probably true. Benjamin is going to talk to the X team. There's a proper release now which we could likely package. I imagine he'll report his findings back to the bug soon.

Benjamin Drung (bdrung) wrote :

I talked to the X team. The library was experimental at the beginning, but that has changed. Timo Aaltonen promised to update the package to the upstream release 0.2.0. I will going to prepare a MIR, unless someone else want to do it (Darxus, maybe?).

Darxus (darxus) wrote :

Not particularly, thanks :)

Nicolas Delvaux (malizor) wrote :

While you are at it, why not also enabling the Broadway backend?
It does not require any additional dependency.
I'm using a broadway-enabled Gtk for some months now and I did not ran into any problem.

The relevant bug report is LP: #933641
I have a PPA here: https://launchpad.net/~malizor/+archive/gtk-broadway

Benjamin Drung (bdrung) wrote :

We discussed the enablement of the Broadway backend on #ubuntu-x and answered in bug #933641 that enabling the Broadway backend makes sense for GTK >= 3.7.

Timo Witte (spacefish) wrote :

yay wayland support and eventually broadway :)

Darxus (darxus) wrote :

Looks like Timo did the libxkbcommon v0.2.0 package. So next step is a MIR for it? Benjamin?

Fred (eldmannen+launchpad) wrote :

There is a MIR for libxkbcommon now.
LP: #1102678

Benjamin Drung (bdrung) wrote :

Thanks for doing it. It has been on my todo list, but I haven't found time to do it.

Darxus (darxus) wrote :

The libwayland0 MIR has been closed "fix committed". So everything should be ready to enable the wayland backend in the gtk package? Iain / Benjamin?

Benjamin Drung (bdrung) wrote :

Thanks for your contribution. I have uploaded gtk+3.0 3.6.4-0ubuntu2 with enables the Wayland backend.

Changed in gtk+3.0 (Ubuntu Raring):
status: Triaged → Fix Committed
Darxus (darxus) wrote :

Great, thanks.

Timo Witte (spacefish) wrote :

https://launchpad.net/ubuntu/+source/gtk+3.0/3.6.4-0ubuntu2/+build/4247991 looks like the build failed...

E: Unable to locate package libxkbcommon-dev
apt-get failed.

Benjamin Drung (bdrung) wrote :

That was expected. We have a main inclusion request (MIR) for libxkbcommon, which got accepted. The package gets moved from universe to main when an other package (in our case gtk+3.0) build depends on it. The build is retried after the move.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gtk+3.0 - 3.6.4-0ubuntu2

---------------
gtk+3.0 (3.6.4-0ubuntu2) raring; urgency=low

  * Enable Wayland backend (LP: #954352)
 -- Darxus <email address hidden> Fri, 25 Jan 2013 22:48:49 +0100

Changed in gtk+3.0 (Ubuntu Raring):
status: Fix Committed → Fix Released
Fred (eldmannen+launchpad) wrote :

To run from X just run 'weston'.
To run from console first run 'sudo chmod +s /usr/bin/weston-launch' and then run 'weston-launch' (do not run 'weston' directly!)

To run GTK applications, you first have to run 'export GDK_BACKEND=wayland'.

Note that GTK applications does not have any window decorations.
Note that Weston does not respect keyboard language settings.

== Works ==
* gnome-calculator
* baobab works
* file-roller (crash on exit)
* charmap
* gwibber
* brasero (crash on exit)
* gnome-sound-recorder (crash on exit)

== Does not work ==
* gnome-terminal
* gedit
* gnone-suduku
* gnome-system-monitor (segfault)
* rhythmbox (segfault)
* nautilus
* totem
* chromium, firefox, xchat, vlc

Fred (eldmannen+launchpad) wrote :

gedit and gnome-terminal actually works if you run them via dbus-launch.

dbus-launch gedit
dbus-launch gnome-terminal

Rico Tzschichholz (ricotz) wrote :

@bdrung, Laney: Hi, is it intended to have the udeb built with the wayland-backend confflag too.

Artem Vorotnikov (skybon) wrote :

Now with the change of plans, is it time to remove wayland from gtk+ dependencies?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.