Bug 615 - PBuffer On Second X Screen Fails
Summary: PBuffer On Second X Screen Fails
Alias: None
Product: Jogl
Classification: JogAmp
Component: x11 (show other bugs)
Version: 2
Hardware: pc_x86_32 linux
: --- major
Assignee: Sven Gothel
Depends on:
Reported: 2012-09-12 15:58 CEST by Rob Hatcherson
Modified: 2012-09-19 20:04 CEST (History)
0 users

See Also:
Type: ---
SCM Refs:
jogl c0cc74a7d525aaa7eb89f60c836589678053d5fb
Workaround: ---

X11GLXDrawableFactory version with patch for pbuffers on a second X screen. (30.98 KB, text/x-java)
2012-09-12 15:58 CEST, Rob Hatcherson

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Hatcherson 2012-09-12 15:58:33 CEST
Created attachment 367 [details]
X11GLXDrawableFactory version with patch for pbuffers on a second X screen.

JOGAMP/JOGL version RC10
Fedora 12
Sun/Oracle JDK 7u7
NVIDIA driver version 304.37

We have some PBuffer code that was working until we tried to move it to a second X screen (not TwinView, but a second screen as in DISPLAY=":0.1").  After we did that an attempt to make the PBuffer's context current threw a GLException.

We investigated and found that during the createGLPbuffer call we ended up at a spot in X11GLXDrawableFactory that assumed screen 0.  In RC10 there are two such places in X11GLXDrawableFactory, on lines 240 and 517 in the original RC10 file.  They look like this respectively:

240: final X11GraphicsScreen sharedScreen = new X11GraphicsScreen(sharedDevice, 0);

517: final X11GraphicsScreen screen = new X11GraphicsScreen(device, 0);

As an experiment we changed these two lines to get the screen number from some nearby connection.  After we made this change the problem disappeared and the PBuffer code started working again.  The modified lines look like this (line numbers changed due to the addition of a new method at the top of the class):

263: final X11GraphicsScreen sharedScreen = new X11GraphicsScreen(sharedDevice, X11GLXDrawableFactory.getScreenNumberFrom(connection) );

540: final X11GraphicsScreen screen = new X11GraphicsScreen(device, getScreenNumberFrom( device.getConnection() ) );

...where getScreenNumberFrom(String connection) is a new method we added to pull the screen number from a connection string.  Note that there probably is a simpler way to do this.

The attached file is our modified version of X11GLXDrawableFactory.java.  The changes are the two modified lines noted above, plus the new "getScreenNumberFrom" method which currently is located near the top of the class.  Keep in mind that we were making changes in areas where our expertise is limited, so I strongly recommend that smarter minds than ours further evaluate this "fix" for correctness.  It makes sense that an assumption of screen 0 all the time might eventually cause problems, but who knows.

Also, the "getScreenNumberFrom" method works well enough, but it seems like either a) the screen number should already be conveniently available from some other spot i.e. we shouldn't have to parse it out of a DISPLAY String, or b) a utility method such as this probably belongs in some other place, e.g. X11Utils, or some display/connection class, etc. assuming a better place already exists.
Comment 1 Sven Gothel 2012-09-17 03:33:00 CEST

    Fixes Bug 615 - X11: Use proper screen index/name for shared resources and device 
    denominated 'mutable' surfaces (dummy, offscreen, ..)
    Fix follows findings of Rob Hatcherson, but instead of parsing the display connection ourself
    we use the X11 macro 'DefaultScreen(display)'
    See <http://tronche.com/gui/x/xlib/display/opening.html#Display>
    "The screen number specified in the display_name argument is returned by the DefaultScreen() macro
    (or the XDefaultScreen() function)."
    Since I currently have no two-head X11 setup here, only xinerama via virtualbox,
    pls test / validate.
    Note: One Display connection may span multiple screens, i.e.:
      display 'lala:0.1' may span from screen 1 - 3 (non xinerama mode)
    [1] How to validate whether a screen number belongs to one display connection ?
    We can query ScreenCount(display), however it is not clear what the range would be.
    [2] With 1 display connection spanning multiple screens, what is/are the proper connection string[s] ?
    [3] After all, it seems this ancient configuration really cannot beat a modern setup w/ XRandR
        having Xinerama enabled. The latter is the default anyways.
Comment 2 Rob Hatcherson 2012-09-19 20:04:38 CEST
The pbuffer problem no longer happens with a build from repos cloned on 09/17/2012.  However, we started getting the problem discussed here instead:


My initial reaction is that this shutdown issue is not related to your improved fix for this pbuffer problem, as much has also changed in the X11 shutdown area.

I can't add any valuable response to discussion points 1) and 2) yet, but will think about them.

Regarding discussion point 3), we use the separate screen approach because the absolute coordinate system that's established on the second screen makes it easier to set up touchscreen drivers.  The fellow here that usually does that setup says it's a bigger pain with e.g. TwinView.  I'd stop short of calling him an X super guru, but he does know a lot about it and I suspect if a better answer existed then he would already be using it.  We could be missing a nicer alternative though, and are always open to suggestions.