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.
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.
> 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.
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.
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.
Qt 5's xcb platform plugin does use both libxcb and Xlib, for the reason you mention and others. Thus hardware accelerated OpenGL is supported on Linux, even with proprietary graphics drivers.
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.
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.
> 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.
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.
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.
And see this, XCB has been around at least since 2006 (when I first heard about it)
The X model was good, but now it's a hinderance. A really big one.
Give the developers a smart framebuffer (I'm not sure linux fb has any hw acceleration features, but IIRC it doesn't) or just give a "Pure" OpenGL API to the developers. And build from that
Oh and by the way, try OSX, it's weird at first but I haven't looked back.
>Give the developers a smart framebuffer (I'm not sure linux fb has any hw acceleration features, but IIRC it doesn't) or just give a "Pure" OpenGL API to the developers. And build from that
That simplicity is more or less the philosophy behind Wayland. You get a buffer to draw into with OpenGL, some extra stuff for interoperability between programs (drag and drop, window decoration) and that's more or less it.
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 :)
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 ;)
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.
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.
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.
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.