4 ms·
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
by pdw 14y ago
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/ 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.
- capisce 14y agoQt 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.
- evmar 14y agoThe 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 14y ago> 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 14y agoThat 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 14y agoI 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.