Bug 789617

Summary: glXQueryVersion blocks if run from different vt than X server
Product: [Fedora] Fedora Reporter: Alon Levy <alevy>
Component: xorg-x11-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: airlied, dblechte, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-13 13:39:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alon Levy 2012-02-11 20:05:58 UTC
Description of problem:
The following program prints "1.4" if run from the same vt (for instance in a pty of gnome-terminal running on the same server) of the Xorg instance, but blocks if run from a different vt.

#include <stdio.h>
#include <X11/X.h>
#include <GL/glx.h>

int main()
{
    Display *dpy;
    int major;
    int minor;
    Bool ret;

    dpy = XOpenDisplay(NULL);
    if (!dpy) {
        printf("XOpenDisplay failed\n");
        return -1;
    }
    ret = glXQueryVersion(dpy, &major, &minor);
    if (ret) {
        printf("%d.%d\n", major, minor);
    } else {
        printf("glXQueryVersion failed\n");
        return -2;
    }
    XCloseDisplay(dpy);
    return 0;
}


Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.11.99.901-3.20120124.fc17.x86_64

How reproducible:
100%

Steps to Reproduce:
1. change vt (ctrl-alt-f2 if you run the default X launched by gdm)
2. run the program above (compiled with gcc query.c -lX11 -lGL -o query)
  
Actual results:
Program blocks in the glXQueryVersion command, stacktrace shows xcb (I'll attach the full one later). (didn't manage to debug the X side yet):


Expected results:
prints "1.4" (on version given above)

Additional info:

Comment 1 Dave Airlie 2012-02-12 17:51:47 UTC
all GLX clients are blocked on VT switch.

Comment 2 Alon Levy 2012-02-13 09:53:49 UTC
My actual problem is not with the test program, it's with gnome shell and with a delay in the tens of seconds after returning from suspend. But I see now that when trying to find what it was being stuck in I did:
 1. change vt
 2. attach with gdb
 3. backtrace

3 showed me the glXQueryVersion was blocking, but if any vt change causes all GLX clients to block then I'll need to debug this differently.

Why are GLX clients blocked on vt switch? is it possible this interacts badly with suspend (i.e. does suspend include a vt switch that gnome-shell doesn't anticipate)? I'll close this if there is nothing new here.

Alon

Comment 3 Dave Airlie 2012-02-13 10:46:36 UTC
they are blocked because for security you don't generally want DRI apps scraping your screen in the background.

there are other reasons though but that is probably the main problem until we get some sort of hw virtual address space.

gnome-shell does have some animation problems 
https://bugzilla.gnome.org/show_bug.cgi?id=653833

that might be relevant.

Comment 4 Alon Levy 2012-02-13 13:39:34 UTC
(In reply to comment #3)
> they are blocked because for security you don't generally want DRI apps
> scraping your screen in the background.
> 
> there are other reasons though but that is probably the main problem until we
> get some sort of hw virtual address space.
> 
> gnome-shell does have some animation problems 
> https://bugzilla.gnome.org/show_bug.cgi?id=653833
> 
> that might be relevant.
Thanks, tried this patch [1], though I had to fix some merges (applied to gnome-shell-3.3.5-2.fc17.x86_64), and it didn't help. Checked by changing vt and returning - hangs (it eventually leaves it. nothing in /var/log/messages).

I'll close this bug since it isn't one.

[1] http://bugzilla-attachments.gnome.org/attachment.cgi?id=207427