Whoops, There's A Big Problem For Wayland GTK+

[Licaon]

some updated info regarding the nVidia stuff: http://lists.freedesktop.org/archive...ch/002798.html

[Darxus]

Thanks, I missed that. Benjamin Otte's reply seems unhelpful. You don't need dlsym, you just need dlopen before calling gl stuff.

Please, tell him that. I don't even know what dlsym is.

[md1032]

Assuming by "they" you mean cairo-gl, the way to ask this question is by opening a bug against cairo, which I did, and which is linked to in the post I wrote which this article says it is is based on. And an answer was provided before you posted your question.

Thanks, I missed that. Benjamin Otte's reply seems unhelpful. You don't need dlsym, you just need dlopen before calling gl stuff.

[Darxus]

If I'm reading this correctly, they're loading libGL into every application linked against GTK+ whether it uses OpenGL or not. Why can't they just call dlopen on it when they decide they need it?

Assuming by "they" you mean cairo-gl, the way to ask this question is by opening a bug against cairo, which I did, and which is linked to in the post I wrote which this article says it is is based on. And an answer was provided before you posted your question.

[Darxus]

....we may simply maintain X11 versions of everything until the situation changes, and allow users with other hardware to use Wayland and cairo-gl.

That's the problem, it can't be done. cairo-gl cannot be packaged in a way that is usable for people using open source video drivers, without breaking X for everybody using the Nvidia proprietary drivers. At least using Debian packages, I don't know about others.

So, to avoid breaking X for the people using Nvidia proprietary drivers, Ubuntu, for example, has disabled cairo-gl for everyone. After putting what looks like a lot of work into trying to find a better solution, and failing. And this is one of the things preventing GTK+ applications from being usable with wayland in Ubuntu 12.04 Precise (the other is a clipboard problem with multiple simultaneously enabled backends).

I explained this in the post the article is based on. One of the possible solutions is adding flexibility to the way Debian packaging works. A Debian bug that's been open for 15 years.

[cookiecaper]

My hope is that nVidia has a private branch where they hack on porting their drivers to all of the Linux techs it doesn't support, including Wayland, KMS, Gallium, et al and that this major reworking will also bring Optimus support &c. As this branch would currently be experimental, nVidia refuses to acknowledge any plans to support these officially since doing so may be considered binding.

Also, hasn't there been a job opening for a Linux driver engineer on nvnews.net for like three or four years? Someone qualified should apply and fill that, maybe you can help get the support we need.

[Ansla]

I didn't realize point 3, that's an important note there. Who cares about 32 bit distros these days?

Well, since Ubuntu promoted the 32 bit version as the preferred one even on 64 bit hardware until now it's to be expected that a lot of Ubuntu users will continue using the 32 bit version for the next several releases. For the rest of the distros, indeed, 32 bit is a rarity. So maybe a better title for this article would have been "Whoops, There's A Big Problem For Ubuntu"

[smitty3268]

3. It only happens for 32 bit applications, because the AMD64 architecture doesn't support shared libraries built with position dependant code so nVidia was forced to fix their 64 bit driver.

I didn't realize point 3, that's an important note there. Who cares about 32 bit distros these days?

[Nille]

Really? Bridgman say some time ago there is packaging problems with EGL in desktop driver. You mean desktop driver or embedded driver? Embedded driver have EGL, yes.

I mean the desktop driver. since some time ago its in the fglrx.

[Ansla]

5 pages of comments and nobody read/understood the article, the usual for Phoronix. Anyway, if anybody is interested in the real problem here is a summary:

1. When building GTK+ with Wayland support memory usage will increase when running on regular X11, so it has nothing to do with nVidia supporting Wayland.

2. This is because 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+)

3. It only happens for 32 bit applications, because the AMD64 architecture doesn't support shared libraries built with position dependant code so nVidia was forced to fix their 64 bit driver.