XLib Resource/Window creation problem

[code_glitch]

So I recently moved to unity from cinnamon on the desktop (cinnamon 2.0 keeps locking up on my hardware spec, not Llano based laptop, trinity based laptops, an older 4X series card - only my desktop) which is what causes me to look into this.

The situation is this: on certain desktop environments (IceWM, E17, fluxbox) I cannot get a window open - and everything crashes with the following output:



X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Serial number of failed request: 24
Current serial number in output stream: 30


I initially looked into this when trying to embed a program into a lightweight debian install. I tried debugging the code but XLib wasnt throwing anything out of the ordinary (at least not compared to the material I could find). HOWEVER: This did not happen if I had metacity running, so I could run my programs on KDE, Cinnamon, Gnome (2 and 3, including Mate) and the old unity. I assumed this was down to compositing or something fun and never thought much of it. Except I'm now looking at a composited desktop through the same compiz compositor I used to run and its now crashing with no changes to the XLib code.

So, does this ring any bells for anyone?

In case I'm doing something extremely idiotic, here is the code thats getting XLib to make the window:


procedure oX11Window.CreateWindow(X, Y, BPP: Int64);
var
FeedEvent: tXEvent;

begin
dpy := XOpenDisplay(Nil);

if Dpy = Nil then
DebugWriteln('Error connecting to X Server');

WindowHeight := Y;
WindowWidth := X;
OriginalWindowHeight := Y;
OriginalWindowWidth := X;

if (BPP <= 0) or (BPP >= Attributes[2]) then
BPP := Attributes[2] //24 bit is a good default if you you dont want anything specific
else
Attributes[2] := BPP;

BitDepth := Attributes[2];

Root := DefaultRootWindow(Dpy);
Vi := glXChooseVisual(Dpy, 0, Attributes);

if Vi = Nil then
DebugWriteln('No Visual found');

cmap := XCreateColormap(Dpy, Root, Vi^.Visual, AllocNone);

Swa.ColorMap := Cmap;
Swa.Event_Mask := ExposureMask Or KeyPressMask Or KeyReleaseMask or PointerMotionMask Or ButtonPressMask Or ButtonReleaseMask or StructureNotifyMask;

Win := XCreateWindow(Dpy, Root, 0, 0, WindowWidth, WindowHeight, 0, Vi^.Depth, InputOutput, Vi^.Visual, CWColormap Or CWEventMask, @Swa);

XSelectInput(Dpy, Root, Swa.Event_mask);
XMapWindow(Dpy, Win);

XStoreName(Dpy, Win, PChar(Name));

Glc := glXCreateContext(Dpy, Vi, Nil, True);
DebugWrite('CTXT');
glXMakeCurrent(Dpy, Win, Glc);

glEnable( GL_TEXTURE_2D );
glClearColor( 0.0, 0.0, 0.0, 0.0 );
glViewport( 0, 0, WindowWidth, WindowHeight );
glClear( GL_COLOR_BUFFER_BIT );
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
glOrtho(0, WindowWidth, WindowHeight, 0, -16, 16);
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();

KillAtom := XInternAtom(Dpy, 'WM_DELETE_WINDOW', 0);
WMDataAtom := XInternAtom(Dpy, 'WM_PROTOCOLS', False);

XSetWMProtocols(Dpy , Root, @KillAtom, 1);

//enable fullscreen mode if requested
if FullScreen = True then
begin
WMStateAtom := XInternAtom(Dpy, '_NET_WM_STATE', False);
WMFullScreenAtom := XInternAtom(Dpy, '_NET_WM_STATE_FULLSCREEN', FullScreen);
with FeedEvent do
begin
_Type := ClientMessage;
XClient.Window := Win;
XClient.Message_type := WMStateAtom;
XClient.Format := 32;
XClient.Data.L[0] := 1;
XClient.Data.L[1] := WMFullScreenAtom;
XClient.Data.L[2] := 0;
XSendEvent(Dpy, DefaultRootWindow(Dpy), False, SubStructureNotifyMask, @FeedEvent);
end;
end;
end;


Edit: The exact line that seems to be dodgy is this:


GlXMakeCurrent(Dpy, Win, Glc);

Which is strange seeing as according to the manual BadAccess being thrown is something to do with a colour map when creating the window is it not?

[code_glitch]

So, I've done some looking and it seems that the BadAccess is supposedly caused by trying to make an opengl current while it is being used by another thread. However - the same binary works fine on most desktop environments (cinnamon, gnome 2.x and 3.x, IceWM (with metacity running)) but not on unity and lxde (sometimes - this one is hit and miss).

Thus, I tested it in a single threaded program - with exactly the same results under the troublesome desktop environments. GDB is of no use at all as it thinks the program terminated successfully and thus refuses to give me a trace of any kind.

Is anyone aware of anything that could cause this behaviour to happen or of some technical reason why some desktop environments are causing this/ The only workaround for the time being is to switch to the SDL backend which is slow, buggy and lacking (no FBOs and such).

[SilverWarior]

So, I've done some looking and it seems that the BadAccess is supposedly caused by trying to make an opengl current while it is being used by another thread. However - the same binary works fine on most desktop environments (cinnamon, gnome 2.x and 3.x, IceWM (with metacity running)) but not on unity and lxde (sometimes - this one is hit and miss).

Thus, I tested it in a single threaded program - with exactly the same results under the troublesome desktop environments. GDB is of no use at all as it thinks the program terminated successfully and thus refuses to give me a trace of any kind.

Another thread doesen't just mean another thread of your application. It could mean another thread of any application even the OS for that mater. And based on my short survey Unity shell is GPU acelerated. So there is a remote posibility that your application can't sucsessfully get OpenGL hande becouse the OS already has one.

Just my thoughts. They might be compleetly off since I have no expirience with Linux development.

[code_glitch]

Ah, thats some useful insight... That said - gnome 3 and cinnamon are also gpu accelerated so I guess it would be a unity issue.

Though the problem has gotten to the point of being enough of a nuisance to prompt me to rewrite the entire X11 code seeing as I can't get any work done until this is fixed. Once thats done, I'll see if I can get it to replicate the behaviour on the new X11 implementation to see what causes this because my code seems to be very similar to numerous xlib/opengl tutorials on the internets...

[SilverWarior]

I might know what your problem is. I reread your first post a few times and if I understand you correctly you don't encounter problems when you have Metacity running. Now based on Wikipadia Metacity is default Window manager used in Gnome 2 Desktop enviroment but it was replaced with Mutter in Gnome 3.
http://en.wikipedia.org/wiki/Metacity
http://en.wikipedia.org/wiki/Mutter_(window_manager)
Cinnamon uses Muffin which is a fork of Gnome 3 Mutter Windows manager.
http://en.wikipedia.org/wiki/Cinnamon_(software)

So all of your problems might be the result of changed default Window manager which probably requires a different code to work.

[code_glitch]

That does make sense - which means I might be doing something that only metacity allows and other WMs do not... Thus, once I finish the rewrite of the code and get it working, I'll do a quick compare to see whats throwing things for a loop.