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 Intel/32-bit 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.
<http://jogamp.org/git/?p=jogl.git;a=commit;h=c0cc74a7d525aaa7eb89f60c836589678053d5fb> 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) Discussion: [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.
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: http://forum.jogamp.org/JVM-Crash-During-X11-Shutdown-tc4026218.html 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.