Results 1 to 6 of 6

Thread: XLib Resource/Window creation problem

  1. #1
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45

    XLib Resource/Window creation problem

    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:

    Code:
    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:
    Code:
    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:
    Code:
    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?
    Last edited by code_glitch; 13-05-2014 at 10:52 PM.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  2. #2
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    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).
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  3. #3
    Quote Originally Posted by code_glitch View Post
    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.

  4. #4
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    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...
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  5. #5
    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.

  6. #6
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    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.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •