The problem I am facing is that I have a glx based application that will render basic primitives on a single thread just fine. I can move the XWindow between both Screens and my rendering loop keeps going. However, if any portion of my application has threads, even if it does not make any openGL calls or touch the XWindow on any other thread but the main thread the graphics I render are lost when I move the XWindow from one screen to the other.
The very first function call that I make is XInitThreads, so I know that X11 should be thread safe. As I said this works when drawing primitives on one thread, but it does not work when I add 1 or more threads. The threads are in a library that I do not have access to the source. I am just being asked to create the windowing portion of the code using X11.
What things should I be looking for to fix this?
Also note I have been guarnteed that all glcalls hapen on the thread I call them from inside the library.
Update
[matt6809@hogganz400 SampleApp]$ cat /etc/X11/xorg.conf && echo "--------" && xrandr --verbose && echo "-------" && glxinfo && echo "-------" && xdpyinfo
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings: version 295.20 (buildmeister@swio-display-x86-rhel47-05.nvidia.com) Mon Feb 6 22:13:16 PST 2012
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig: version 295.20 (buildmeister@swio-display-x86-rhel47-05.nvidia.com) Mon Feb 6 22:13:40 PST 2012
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "1"
EndSection
Section "Files"
FontPath "/usr/share/fonts/default/Type1"
EndSection
Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
# generated from data in "/etc/sysconfig/keyboard"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbLayout" "us"
Option "XkbModel" "pc105"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "DELL P190S"
HorizSync 30.0 - 81.0
VertRefresh 56.0 - 76.0
Option "DPMS"
EndSection
Section "Monitor"
Identifier "Monitor1"
VendorName "Unknown"
ModelName "DELL P190S"
HorizSync 30.0 - 81.0
VertRefresh 56.0 - 76.0
Option "DPMS"
EndSection
Section "Monitor"
Identifier "Monitor1"
VendorName "Unknown"
ModelName "DELL 1908FP"
HorizSync 31.0 - 83.0
VertRefresh 56.0 - 76.0
EndSection
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "Quadro 4000"
BusID "PCI:15:0:0"
Screen 0
EndSection
Section "Device"
Identifier "Device1"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "Quadro 4000"
BusID "PCI:15:0:0"
Screen 1
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "TwinView" "0"
Option "TwinViewXineramaInfoOrder" "DFP-0"
Option "metamodes" "DFP-0: nvidia-auto-select +0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection
Section "Screen"
Identifier "Screen1"
Device "Device1"
Monitor "Monitor1"
DefaultDepth 24
Option "TwinView" "0"
Option "metamodes" "DFP-2: nvidia-auto-select +0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection
--------
Xlib: extension "RANDR" missing on display ":0.0".
RandR extension missing
[matt6809@hogganz400 SampleApp]$
It's just a hunch, but it might be, that the OpenGL contexts are not cleanly migrated between threads. Your question doesn't make it clear, if you have full control over OpenGL and windowing operations.
The usual approach when it comes to OpenGL and multithreading is to keep all OpenGL operations confined to only one particular thread.
If you can not make sure of this, you should call
glXMakeContextCurrent(display, None, None, NULL); // GLX 1.3
or
glXMakeCurrent(display, None, NULL); // GLX 1.2 and earlier
after finishing OpenGL operations before yielding to another thread or finishing the tasklet to make sure the context is properly unbound from the current thread.
Rebind the context accordingly when needed.