Irrlicht GLX Error on Allegro Display
Robert MacGregor


This appears to be more of an Irrlicht issue than it is Allegro, so this thread more or less functions as a way for me to get comments from Allegro developers about an
issue I've been having quite recently as they may be able to help shed some light on
it as well.

I'm using Irrlicht for a project and I'm trying to delegate Irrlicht to just being a renderer and so I've brought in Allegro to handle mouse/keyboard input which requires an Allegro display to be active, so I'm using the Irrlicht createDeviceEx method to initialize Irrlicht with the XID of the created Allegro window as such:

1#include <iostream> 2 3#include <irrlicht/irrlicht.h> 4 5#include <allegro5/allegro.h> 6#include <allegro5/allegro_x.h> 7 8int main(int argc, char* argv[]) 9{ 10 // Init Allegro & create a display 11 al_init(); 12 13 ALLEGRO_DISPLAY* allegroDisplay = al_create_display(640, 480); 14 15 if (!allegroDisplay) 16 { 17 std::cout << "Failed to create Allegro Display" << std::endl; 18 return -1; 19 } 20 21 al_set_window_title(allegroDisplay, "Allegro/Irrlicht Test"); 22 23 // Setup the creation parameters 24 irr::SIrrlichtCreationParameters creationParameters; 25 creationParameters.DriverType = irr::video::EDT_OPENGL; // If this is EDT_BURNINGSVIDEO or EDT_SOFTWARE, it behaves as expected. 26 creationParameters.WindowId = reinterpret_cast<void*>(al_get_x_window_id(allegroDisplay)); 27 28 // Init Irrlicht 29 irr::IrrlichtDevice* irrlicht = irr::createDeviceEx(creationParameters); 30 irr::scene::ISceneManager* scene = irrlicht->getSceneManager(); 31 irr::video::IVideoDriver* video = irrlicht->getVideoDriver(); 32 33 // Setup a scene so we can see if it actually renders 34 scene->addCameraSceneNode(); 35 36 irr::scene::ISceneNode* cube = scene->addCubeSceneNode(); 37 cube->setMaterialFlag(irr::video::EMF_LIGHTING, false); 38 cube->setPosition(irr::core::vector3df(0, 0, 50)); 39 40 // Roll out a basic draw loop 41 while (irrlicht->run()) 42 { 43 video->beginScene(); 44 scene->drawAll(); 45 video->endScene(); 46 } 47 48 return 0; 49}

I'll note right now that you'll need a source build of Allegro's unstable branch 5.1 because the al_get_x_window_id method was something I very recently implemented:

And this is literally all it does when called: which simply returns the XID of the window.

The problem? The application exits when you try to initialize Irrlicht with an OpenGL video driver using an Allegro window with the following error:

1Linux 4.0.5-gentoo-tye #15 SMP Tue Aug 25 00:34:19 EDT 2015 x86_64 2X Error of failed request: BadMatch (invalid parameter attributes) 3 Major opcode of failed request: 153 (GLX) 4 Minor opcode of failed request: 31 (X_GLXCreateWindow) 5 Serial number of failed request: 22 6 Current serial number in output stream: 23

I've gone through and changed a bunch of Irrlicht initialization parameters as well as Allegro window creation parameters and none of it seems to have yielded any sort of effect on the output at all. The thing that has me especially confused is that it does work the way it should if you tell Irrlicht to use Burning's Video or the regular Software Renderer (as shown in the attached image.)

I'm not entirely sure why it isn't working with OpenGL, so I was hoping someone would be able to speculate on the issue at least.

Here is relevant system information:

1ragora@tye ~ $ uname -r 24.0.5-gentoo-tye 3ragora@tye ~ $ gcc --version 4gcc (Gentoo 4.8.4 p1.6, pie-0.6.1) 4.8.4

Irrlicht Version 1.8.1 on an ~AMD64 Gentoo system using KDE4.


I notice you don't seem to set up an OpenGL environment, which would explain the crash of the OpenGL renderer of Irrlicht. How about adding somethng like...


.. or similar flags or options with al_set_new_display_options(), before creating the display of course.

Thomas Fjellstrom
beoran said:

I notice you don't seem to set up an OpenGL environment, which would explain the crash of the OpenGL renderer of Irrlicht.

It could, but he's on linux, gentoo specifically. The default, and only driver on linux is OpenGL (currently).

Robert MacGregor

ALLEGRO_OPENGL is one of the things I've tried, which appears to have no bearing on the result. Same for the GL 3.0 flag alone and used in tandem with the regular GL flag.

Also, here's some relevant glxinfo:

1ragora@tye ~/Desktop/AllegroExplode/bin/Debug $ glxinfo | grep version 2server glx version string: 1.4 3client glx version string: 1.4 4GLX version: 1.4 5OpenGL core profile version string: 4.4.0 NVIDIA 352.30 6OpenGL core profile shading language version string: 4.40 NVIDIA via Cg compiler 7OpenGL version string: 4.5.0 NVIDIA 352.30 8OpenGL shading language version string: 4.50 NVIDIA 9OpenGL ES profile version string: OpenGL ES 3.1 NVIDIA 352.30 10OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 11 GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix,

It's also worthwhile to point out that Irrlicht is the one creating the GL context, so Allegro shouldn't have to worry about it I believe. The question more or less regards the possibility that I may have simply overlooked something in Allegro's API when setting this up to work with Irrlicht.

Thomas Fjellstrom

It's also worthwhile to point out that Irrlicht is the one creating the GL context, so Allegro shouldn't have to worry about it I believe.

A GL Context comes with the display it creates. Can you tell Irrlicht to use an existing context?

Robert MacGregor

That was more of a guess if that's the case, then. Irrlicht's API is built to accept arbitrary WindowID's via WindowID:

Though it makes no note as to what it expects about the input window itself; I've actually dropped a similar post onto Irrlicht's forums as well, so I could bring that up with them and see what's going on with that.


After a closer look at the Irrlicht Win32 example, I noticed an SVideoData structure that I seem to have overlooked:

This is used to give Irrlicht some other things such as the OpenGL context as well. Let me try fiddling with that. Though now I don't seem to be able to retrieve the GL context from Allegro to do so.

Well, nevermind all that; the video data is only used in the draw at beginScene; the crash is immediately seen at createDeviceEx well before the video data is even relevant. So now it's either a bug in Irrlicht or I'm simply doing something wrong in Irrlicht's init.


I delved into the question ages ago, I memeber that there's an example in Irrilicht SDK that does just that and handles the GL context that Allegro creates directly to Irrilicht renderer.

I have no time right-no but if you haven't found anything by this evening I mught be able to look into an old archive.

Robert MacGregor

I haven't seen anything dealing with Allegro in the 1.8.1 examples, though I can triple check it. The closest is the Win32 example using a raw Win32 window which I've tried to mimic but it does not work due to the GLX error being raised directly on createDeviceEx. Nobody has responded on their forum so far, either.

Thomas Fjellstrom

I haven't seen anything dealing with Allegro in the 1.8.1 examples, though I can triple check it.

I think what he's saying is there is an example that just takes an existing context and uses that.

Robert MacGregor

Ah, that's the Win32 example but that doesn't really work because the code to actually use existing contexts occurs after createDeviceEx which is raising the GLX error.


Looks like their recent 1.8.2 release may have fixed it. That, or it works on my laptop I just tried it on for other reasons. I'll have to try it on my main box at home when I can. In either case, it looks like it was probably just a bug completely unrelated to Allegro.

Another Edit

No, apparently it works because of my laptop config because 1.8.1 runs fine as well.


Sorry, checked it in a rush and you're correct I only had a win32 exmaple taking an existing context working.

In priciple this can be handled back and forth, but I haven't tried it since I abandoned the idea long ago.

Also, seems you're pretty much on another track :P

Robert MacGregor

Yea, I've at least isolated the cause by now (mostly): It's related to the NVidia driver.

1ragora@tye ~ $ eselect opengl list 2Available OpenGL implementations: 3 [1] nvidia 4 [2] xorg-x11 *

Having the xorg-x11 OpenGL driver selected makes the code behave as expected when using OpenGL, but now I'm restricted to GL 3 on everything and my desktop environment crashes when the app exits normally. So this is more of a system bug than it is anything else at this point. Wretchedly difficult thing to track down, apparently.

Thread #615699. Printed from