
Qt5's Linux Requirements Cause Problems - protomyth
http://www.phoronix.com/scan.php?page=news_item&px=MTE4NTk
======
pdw
This is yet another horrible naming mess. As far as I can figure out, the
following is correct:

There are two things named GLX: First, it's a network protocol for sending
OpenGL requests to an X server. Second, it's a library that X clients use to
set up an OpenGL context. Traditionally, the GLX library used the GLX
protocol, but in these days of client-side rendering the GLX protocol is just
unused legacy junk.

Next, Xlib. Xlib is the traditional client library for the X protocol. I'ts a
huge unmaintainable non-threadsafe mess, too low-level for application
developers but hiding too much of the X protocol for toolkit developers.
Everybody hates it.

As an alternative, the X developers created the XCB ("X C Bindings") library.
XCB is much smaller than Xlib, is thread-safe and gives toolkit devs very fine
control about how they handle X11 communication. XCB-GLX is XCB's
implementation of the obsolete GLX protocol. (Most of XCB is auto-generated
based on protocol descriptions, so it was little extra effort to include it
for completeness.)

Now the GLX library API is still based on Xlib, not on XCB. The X developers
however made sure that a single application could simultaneously use both XCB
and Xlib, <http://xcb.freedesktop.org/MixingCalls/>. So that shouldn't be a
problem.

I don't understand why Qt5 can't use that, and the article doesn't explain.

~~~
evmar
The GLX library (which is implemented in terms of Xlib data types) itself is
implemented by the nvidia driver (it speaks some other driver-internal stuff
to the nvidia kernel-side bits) -- as you mention, rendering is client-side
these days, so the implementing GLX protocol doesn't amount to much.

It is maybe still possible to use enough of of xlib+nvidia-glx in an XCB app
to make things work but I think that's uncharted territory -- and it seems
likely to me nvidia's glx expects you to have the other pieces of xlib around,
such as using xlib's event queues.

~~~
exDM69
> It is maybe still possible to use enough of of xlib+nvidia-glx in an XCB app
> to make things work but I think that's uncharted territory -- and it seems
> likely to me nvidia's glx expects you to have the other pieces of xlib
> around, such as using xlib's event queues.

I've done XCB+Xlib+GLX + proprietary graphics drivers, it does work although
it's sort of uncharted territory but if you're brave you can make it work.
Initialize Xlib as usual, then use XSetEventQueueOwner to enable handling
events with XCB and finally do you GLX stuff with the Xlib Display object.

~~~
stevenlstarr
That was part of my point I have stacks of xlib and glx books/docs xcb's
documentation is severely lacking. I want to write my desktop not fool around
with xlib here and xcb there I am getting old and would like to see Desktop
Linux as a major player in my life time. I just want something concrete xlib
and glx for now gives me that. When wayland is stable enough and has hardware
acceleration for nvidia's binary blobs then Ill move on to that. I dont want
to put all my eggs in one basket on something that might happen.

Nvidia needs to just come out and say yes if wayland proves fruitfull we will
support it.

~~~
evmar
I know this opinion may be unpopular, but: people have been successfully
writing xlib apps for literally decades. There's no reason to use xcb for that
type of app, especially if you're just trying to get a GL window on the screen
and you don't expect to be doing lots of tricky X calls.

------
exDM69
This article is (at least a little) wrong. By the way I wrote the XCB-OpenGL
doc that is cited in this article.

You _can_ use XCB with OpenGL, but you won't be getting rid of Xlib altogether
because of GLX depends on Xlib. It does not mean that you cannot use XCB or
get any advantage out of it.

So you use Xlib+GLX for OpenGL initialization and XCB for events and windowing
stuff. Works like a charm.

> It means that they're forcing us to install and use XCB that doesn't support
> Hardware Accelerated Graphics using your ATI/NVIDIA binary drivers. And it
> ends up reverting back and using XLIB/GLX anyways.

"Forcing us to install" is a rather awkward choice of words since you most
likely do have XCB installed and the version of Xlib you have is built with
XCB.

And the XCB+GLX+Xlib hybrid setup that is detailed in the XCB wiki article
works just fine with Nvidia (and presumably ATI) drivers, with hardware
acceleration.

~~~
stevenlstarr
The point I was trying to make was not that it cant be done but you end up
mixing Xlib and xcb regardless. Its that xcb cant be used stand alone. In that
sense its crippled.

And I build my system from scratch and granted my version of x is older Qt4
never had the xcb requirement, It was always Xlib.

Instead on XLIB+GLX its not XCB+XLIB+GLX

But XCB does nothave support for hardware acceleration it still needs Xlib.

By the way thank you for taking your time and writing those docs, being there
isn't much on XCB as it is. Maybe you can talk some sense into the XCB guys to
take a couple weeks of and document XCB properly.

~~~
exDM69
> The point I was trying to make was not that it cant be done but you end up
> mixing Xlib and xcb regardless. Its that xcb cant be used stand alone. In
> that sense its crippled.

GLX is the weak spot, not XCB. And GLX is not something that we can change.
Hopefully the situation will improve, either through a GLX+XCB backend, EGL or
Wayland.

You can't get rid of Xlib, but you can still benefit from XCB by using it for
the non-gl stuff, which would be the majority of Qt, or any other X11+OpenGL
app for that matter.

And it would make no sense whatsoever to try to use a pre-XCB version of Xlib.
Unlike XCB, which is machine generated and (partially) formally verified, Xlib
has had bugs at a whole different scale.

> By the way thank you for taking your time and writing those docs, being
> there isn't much on XCB as it is. Maybe you can talk some sense into the XCB
> guys to take a couple weeks of and document XCB properly.

XCB is a machine generated library based on X11 specifications. The X11 specs
are the documentation you want, just apply XCB coding conventions like the XCB
source generator does. I don't want to bug the devs, they have better things
to do than writing docs for noobs.

~~~
stevenlstarr
"I don't want to bug the devs, they have better things to do than writing docs
for noobs."

11 years of procrastination nice no wonder half your dev team left to go work
on wayland with an attitude like that.

Hay did you know wayland has docs for noobs
<http://wayland.freedesktop.org/docs/html/>

------
quanticle
And this is why, my friends, we don't have a Linux desktop. At some point, we
need get some stability and backwards compatibility in our GUI toolkits.
Otherwise, we see this problem over and over again - GUI API updates break
application developers, and those developers have to put time and effort into
restoring functionality rather than adding new features or improving
usability.

Windows will happily run 10 year old GUI code. OSX will still run 7 year old
GUI code. But Linux? Depending on the which window manager you're using, even
2-3 year old code can be horribly broken by API updates. As a developer, this
is one of the chief reasons I'm considering abandoning Linux and moving to
OSX. It's just too bothersome to deal with the ever-increasing flux in Linux
GUI libraries.

~~~
SeanDav
I thought Ubuntu was the one distro that was moving towards a consistent
desktop.

I think somehow that consistency in the unix/linux world is an anathema, with
a good old whack of NIH syndrome.

~~~
Zak
Ubuntu created a new shell on top of Gnome 3. I'm not sure how that makes for
more consistency. Unity is not widely adopted outside of Ubuntu and Gnome 3 is
so unpopular that there are two projects to keep Gnome 2 around; Mate, a fork
of Gnome 2 and Cinnamon, a layer on top of Gnome 3 that has a UI similar to
Gnome 2.

------
dguaraglia
I love how there's a certain amount of rational explanation and then the
closing one line "the reason I'm so pissed off, blah blah blah". It's
genuinely funny for some reason :)

~~~
stevenlstarr
Yahhh have a bunch of your code base broken when they remove a major class and
not tell anyone then dont provide an alternative and you won't think its very
funny my friend ;)

------
nicholassmith
Whilst I agree some of the choices they've made for Qt5 are right now not
great, there's no forced upgrade to Qt5. Qt4.8 will still see fixes, the
source is there, all will be well.

I do get where the ranter/writer is coming from, it's one of the reasons I'm
holding off on going Qt5 for any big projects.

------
zem
correct me if i'm wrong, but qt4.x should happily coexist with qt5.x,
providing all the legacy support the author might require. i'd be surprised if
qt4 didn't get backported fixes and possibly even features from the 5.x
branch, especially if a lot of popular apps end up still depending on it.

~~~
stevenlstarr
There not planning to replace the QX11Info() class the removed and independent
had to start coding a replacement and apparently he needs help. The XCB
docs/tutorials are almost non-existent and do to that I never bothered to pick
it up so I cant help him. You don't remove a class like that and not tell any
one or provide a replacement. Its rude.

They didn't bother to take consideration for those that were using those
api's. Now all my codes broken and I have to hope that guy writing the XCB
QX11Info() class for the xcb comes threw or I have to replace thousands of
lines of code.

