Thank You, Dmitri, for your help. Taking into consideration what you described, I tried a few more things out. Turns out, my assumption about which display device was the primary display (i.e. Display 0) in my Linux setup was incorrect. I have a digital flat panel and an analog CRT connected and it turns out that the analog CRT is actually the primary display and upon dragging my opengl enabled window to that physical display I begin to see OGL calls in my trace output. If the window is on the second display (i.e. Display 1) it appears that OpenGL acceleration desists and the X11 pipeline takes over. So, when it says it didn't enable opengl on screen 1, I guess it really means it!
However, I still don't think everything is behaving properly. From the NVidia Linux driver documentation Twinview should behave as such:
- The NVIDIA driver conceals all information about multiple display devices from the X server; as far as X is concerned, there is only one screen.
- Both display devices share one frame buffer. Thus, all the
the functionality present on a single display (e.g.accelerated OpenGL) is available on TwinView
It seems to me the exact opposite is happening with Java, i.e. it is seeing two distinct displays when it should only be seeing one.
There is an option called "NoTwinViewXineramaInfo" that disables Twinview's xinerama information.
When in TwinView, the NVIDIA X driver normally provides a Xinerama extension that X clients (such as window managers) can use to to discover the current TwinView configuration. Some window mangers can get confused by this information, so this option is provided to disable this behavior.
So when I enable the NoTwinViewXineramaInfo
option, I effectively get only one very large, opengl accelerated screen called "screen 0" and my opengl window runs via the OpenGL pipeline on both physical displays. Unfortunately, though, this effectively cripples the Linux window manager which now no longer honors the bounds of the physical displays.
As such, it seems to me that either Java is asking the Nvidia drivers the wrong question when querying the opengl capabilities of the physical device or
the NVidia drivers are providing back the wrong answer.
As far as enabling opengl with the System.setProperty, you we're right. I hadn't realized static 2D calls were being made elsewhere in advance of the static main method. So I'll have to rethink how I allow the user to adjust that property. I realize that OpenGL isn't enabled by default for a reason, but unlike Windows which has multiple fallback methods, it seems to me that there is no good, accelerated alternative to X, so I intend to provide the user with the ability to run in some sort of safe mode using the X11 pipeline if they notice display problems.