OpenGL display problem


17 posts
by davef21370 » Sun Dec 16, 2012 8:14 am
I've installed Box2D and built it without a problem but when I try to run Testbed I get the following...

freeglut (./Testbed): OpenGL GLX extension not supported by display ':0.0'

Mr.Google points towards the graphics drivers not being installed properly but I don't want to start meddling with stuff if I don't need to.

Any help much appreciated.
Dave.
Please feel free to tap into my abundant lack of knowledge.
User avatar
Posts: 422
Joined: Fri Sep 21, 2012 4:13 pm
Location: Up North
by PeterO » Sun Dec 16, 2012 8:21 am
There is no support on the PI for the GLX extension for running OpenGL ES from within X windows.
PeterO
User avatar
Posts: 521
Joined: Sun Jul 22, 2012 4:14 pm
by -rst- » Mon Dec 17, 2012 1:46 pm
Seems the freeglut (which Box2D uses) is (not yet) compatible with the OpenGL ES available on RPi.

Someone started a port but gave up: viewtopic.php?f=68&t=25413. There is some info here http://freeglut.sourceforge.net/docs/gles.php.

Might be a bit advanced... :?
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'
Posts: 893
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland
by Narishma » Mon Dec 17, 2012 3:09 pm
PeterO wrote:There is no support on the PI for the GLX extension for running OpenGL ES from within X windows.
PeterO

GLX is for OpenGL. OpenGL ES uses EGL instead to interface with the windowing system.
Posts: 150
Joined: Wed Nov 23, 2011 1:29 pm
by PeterO » Mon Dec 17, 2012 9:24 pm
Narishma wrote:
PeterO wrote:There is no support on the PI for the GLX extension for running OpenGL ES from within X windows.
PeterO

GLX is for OpenGL. OpenGL ES uses EGL instead to interface with the windowing system.

There is no windowing system.
PeterO
User avatar
Posts: 521
Joined: Sun Jul 22, 2012 4:14 pm
by Narishma » Tue Dec 18, 2012 1:48 pm
PeterO wrote:
Narishma wrote:
PeterO wrote:There is no support on the PI for the GLX extension for running OpenGL ES from within X windows.
PeterO

GLX is for OpenGL. OpenGL ES uses EGL instead to interface with the windowing system.

There is no windowing system.
PeterO

Change "windowing system" to "operating system" if that makes more sense to you. Basically OpenGL doesn't care about window management and uses GLX (on Linux, WGL on Windows, CGL on OSX, etc...) to interface with the OS's native window manager. With OpenGL ES, they replaced all those various interfaces with a single cross-platform one called EGL.
Posts: 150
Joined: Wed Nov 23, 2011 1:29 pm
by PeterO » Tue Dec 18, 2012 2:25 pm
Narishma wrote:Change "windowing system" to "operating system" if that makes more sense to you.
I'm not sure who you think doesn't understand the situation, but you are clearly confused about this.

OpenGL ES does not interact with either the windowing system or the operating system.
When you aren't running X windows there is no windowing system to interact with, and
when you are running X windows there is no support for running OpenGL ES within a window.
Neither does it interact with the operating system (Linux).
PeterO
User avatar
Posts: 521
Joined: Sun Jul 22, 2012 4:14 pm
by Narishma » Tue Dec 18, 2012 3:41 pm
PeterO wrote:OpenGL ES does not interact with either the windowing system or the operating system.
When you aren't running X windows there is no windowing system to interact with, and
when you are running X windows there is no support for running OpenGL ES within a window.
Neither does it interact with the operating system (Linux).
PeterO

Of course it does, and it uses EGL to do it since OpenGL ES itself is platform agnostic. It needs a framebuffer surface or pixmap to draw to (eglCreateWindowSurface), it needs some way to tell the OS to display that surface (eglSwapBuffers), synchronization primitives (eglWaitClient), context management (eglBindAPI, eglCreateContext and so on). All those things a few other are interactions with the OS and graphics system/window manager (whether it actually uses windows or is fullscreen is irrelevant).
Posts: 150
Joined: Wed Nov 23, 2011 1:29 pm
by dobova86 » Tue Dec 18, 2012 5:01 pm
I face a problem like this with qt5. I've cross compiled qt5 rc2 libs for raspberry and I use ubuntu 12.10 as main development system. I can create forms and window, also with the qt designer, but when I deploy the compiled program on raspbian wheezy, the main window is always fullscreen and I've no way to resize.
I see that cross compilation with linaro-4.7-g++ is always called with -lGLESv2 library, so probably the qt generated program is running in the GL ES context and not in lxde session. I don't know if I can get rid of this lib in compilation, I didn't find the trick at the moment.
As side effect I see the program running reeaaally fast on raspy !
Posts: 11
Joined: Wed Dec 05, 2012 5:32 pm
by PeterO » Tue Dec 18, 2012 5:39 pm
Narishma wrote:
PeterO wrote:OpenGL ES does not interact with either the windowing system or the operating system.
When you aren't running X windows there is no windowing system to interact with, and
when you are running X windows there is no support for running OpenGL ES within a window.
Neither does it interact with the operating system (Linux).
PeterO

Of course it does, and it uses EGL to do it since OpenGL ES itself is platform agnostic.
Since when was EGL part of the OS ? It's an API layer that sits between user space and the hardware.
It needs a framebuffer surface or pixmap to draw to (eglCreateWindowSurface), it needs some way to tell the OS to display that surface (eglSwapBuffers), synchronization primitives (eglWaitClient), context management (eglBindAPI, eglCreateContext and so on). All those things a few other are interactions with the OS and graphics system/window manager (whether it actually uses windows or is fullscreen is irrelevant).

None of those calls have anything to do with the OS. And again there is no window manager involved.
You 're now on my ignore list so don't bother replying.
PeterO
User avatar
Posts: 521
Joined: Sun Jul 22, 2012 4:14 pm
by PeterO » Tue Dec 18, 2012 5:46 pm
dobova86 wrote:I face a problem like this with qt5. I've cross compiled qt5 rc2 libs for raspberry and I use ubuntu 12.10 as main development system. I can create forms and window, also with the qt designer, but when I deploy the compiled program on raspbian wheezy, the main window is always fullscreen and I've no way to resize.
I see that cross compilation with linaro-4.7-g++ is always called with -lGLESv2 library, so probably the qt generated program is running in the GL ES context and not in lxde session. I don't know if I can get rid of this lib in compilation, I didn't find the trick at the moment.
As side effect I see the program running reeaaally fast on raspy !

OpenGL ES knows nothing about lxde (or Xwindows in general). To use openGL ES you have to link with -lGLESv2 and that will use the egl API to interface with the GPU. If you have the source code for the qt5 libs you may be able to find where the EGL context is created, and from there you may be able make it use less than the whole screen, but it will in no way be integrated with or aware of any lxde windows.
PeterO
User avatar
Posts: 521
Joined: Sun Jul 22, 2012 4:14 pm
by dobova86 » Tue Dec 18, 2012 6:43 pm
Hi PeterO,

Yes that's how it works. I configured with qtbase "./configure -opengl ...", so now I can use window ui interface with no X running, lot of memory & processor free environment.

Ciao
Dome
Posts: 11
Joined: Wed Dec 05, 2012 5:32 pm
by Narishma » Tue Dec 18, 2012 8:40 pm
PeterO wrote:
Narishma wrote:
PeterO wrote:OpenGL ES does not interact with either the windowing system or the operating system.
When you aren't running X windows there is no windowing system to interact with, and
when you are running X windows there is no support for running OpenGL ES within a window.
Neither does it interact with the operating system (Linux).
PeterO

Of course it does, and it uses EGL to do it since OpenGL ES itself is platform agnostic.
Since when was EGL part of the OS ? It's an API layer that sits between user space and the hardware.
It needs a framebuffer surface or pixmap to draw to (eglCreateWindowSurface), it needs some way to tell the OS to display that surface (eglSwapBuffers), synchronization primitives (eglWaitClient), context management (eglBindAPI, eglCreateContext and so on). All those things a few other are interactions with the OS and graphics system/window manager (whether it actually uses windows or is fullscreen is irrelevant).

None of those calls have anything to do with the OS. And again there is no window manager involved.
You 're now on my ignore list so don't bother replying.
PeterO

I said EGL is the interface between OpenGL ES and the OS, specifically the graphics subsystem and/or window manager of the OS, not that it's part of the OS.
Feel free to ignore me though if it makes you happier.
Posts: 150
Joined: Wed Nov 23, 2011 1:29 pm
by davef21370 » Tue Dec 18, 2012 9:04 pm
Could you lot please stop having a cat fight on my post, it's not answering the initial question and not helping anything at all.

Thanks for pretty much nothing!!
Please feel free to tap into my abundant lack of knowledge.
User avatar
Posts: 422
Joined: Fri Sep 21, 2012 4:13 pm
Location: Up North
by Narishma » Tue Dec 18, 2012 9:55 pm
davef21370 wrote:Could you lot please stop having a cat fight on my post, it's not answering the initial question and not helping anything at all.

Thanks for pretty much nothing!!

PeterO has answered your question in his first post. Testbed uses the freeglut library which typically only supports OpenGL, not OpenGL ES. The Pi doesn't have hardware accelerated OpenGL, hence no GLX, hence the error you're getting. To solve this, you'd have to either get an OpenGL ES version of freeglut (there's a topic in these forums where someone is trying to do that) or modify Testbed so it doesn't use freeglut. Another solution would be to install the non-accelerated Mesa OpenGL software implementation but that would run extremely slowly on the Pi's CPU.
Posts: 150
Joined: Wed Nov 23, 2011 1:29 pm
by davef21370 » Tue Dec 18, 2012 10:59 pm
Okay, might have been a touch tetchy accusing you all of having a cat fight but that's what it seems like, apologies to anyone who may require them!

Back on track, is there a half decent graphics library (3D & physics) that can be easily(ish) installed on wheezy so I can get on with some much needed coding?

And again, any help much appreciated.
Please feel free to tap into my abundant lack of knowledge.
User avatar
Posts: 422
Joined: Fri Sep 21, 2012 4:13 pm
Location: Up North
by PeterO » Wed Dec 19, 2012 5:25 pm
You might find something useful in this thread.
viewtopic.php?f=68&t=9693

And there is useful stuff here:
http://benosteen.wordpress.com/2012/04/ ... x-windows/
This includes a port of the examples from the openGL ES 2.0 Programming Guide (which to be honest is not a particularly good book to learn from but is useful once you've understood the basics).

PeterO
User avatar
Posts: 521
Joined: Sun Jul 22, 2012 4:14 pm