There are four general types of OpenGL-based stereo viewing systems today:

1. Hardware with stereo supported by OpenGL, used by applications that know about stereo. This is the ideal situation, and all systems will hopefully work this way someday. This type of application may benefit from StereoGL by having support for stereo setup (like  video-mode selection),  utilities for calculating left/right view transforms, and ability to use common user-preferences for stereo. These types of tools are not ready yet.

 
2. Hardware without OpenGL stereo support, used by software that doesn't know about stereo. These are the newer low-cost stereo devices targeting consumers, mostly 3D games. They work by using library wrappers that intercept the 3D information sent to OpenGL by the application, convert it to left & right views, and display it as needed to work with the stereo hardware. These drivers mostly do not work for applications that know about stereo, which causes a lot of confusion for people trying to use them with true stereo programs.

 
3. Hardware without OpenGL support, with software that knows how to directly produce stereo for a given system.  This usually applies to using a low-cost stereo device like the ones in #2. This used to be the only way to get stereo on Linux, which is why I got interested in this project. This suffers from the problem that all software needs to know about all hardware, causing a lot of incompatibilities and redundant coding efforts.
   
   
4. Simulated OpenGL stereo support, for software that knows about stereo. This approach allows you to use real stereo applications (as in #1) on low cost hardware (as in #2) without the app having to do all the work (as in #3). This is how StereoGL works.

There are so many ways to design such a project that it has been slow to converge on a good design. I have also found that it is hard to get design feedback until you release some testable source code. The current design is to wrap the entire libGL.so. Most of the work occurs in just a few commands, but wrapping the entire library will allow us to track and duplicate drawing commands for left and right views for autogenerated stereo.

In addition to wrapping OpenGL commands, glX and/or GLUT commands must be wrapped for handling window management and framebuffer selection. We are currently focusing on GLUT wrappers, because GLUT apps are much easier to handle. We are also working on glX wrappers, but this will require more debugging due to the larger variety of programming methods available.

   Joe Krahn

Here are a few links to more resources on stereo displays.

SourceForge Project page

Licensing: The code will be released as LGPL so that it will be useable by proprietary applications, but adding support for hardware will require adding open-source code.