How to properly handle double-width framebuffer? Stereoscopic X?

[wdraxinger.maillist at draxit.de]

Am Dienstag 13 April 2010 schrieb Chetan Raj:
> We have a LCD display panel whose real physical dimensions are of
>  ratio 4:3.  However, the panel only accepts framebuffer of
>  resolution 640x240 (8:3).
>
> It would also be helpful if anyone can throw light on such a
>  strange LCD panel configuration that has 4:3 physical dimension,
>  but uses 8:3 pixel ratio.

Maybe the Panel, or its controller are for a stereoscopic display 
system using a lenticular lens in front of it, where the images for 
left and right eye are sent to the display column interlaced. You want 
the double horizontal resolution then.

Intermediary solution: Just configure the monitor with the unusual 
framebuffer size, and use the configuration option "DisplaySize" to 
define it's physical dimensions. While it doesn't help with Pixmaps 
everything rendered from vector data (like TrueType, OpenType, 
Postscript fonts and such) will show with the correct aspect if the 
applications don't abuse the libraries. I'm not sure about what the 
current toolkits do, but it was even possible for them to properly 
stretch pixmaps to match the framebuffer aspect.

ATM I'm quite busy working on stereoscopy systems, and unfortunately 
there's no standards track for it in X11 (yet?).

I'd like to use the opportunity to trigger some discussion. I figured 
for a proper support of stereoscopy, X11 must be extended by at least 
the following:

* windows may be either a single drawable, or a dual/stereo drawable. 
If a window is a "single" drawable, then it must be possible to assign 
it to either "left eye", "right eye" or "both", preferrably not only 
on creation time. Default is single drawable assigned to "both".

* It may desireable to allow overlapping sibling (sub)windows which 
don't share a target drawable (i.e. one set is assigned only "left 
eye" the other "right eye") don't occlude each other to enable stereo 
rendering by creation of multiple windows, placed at the same 
location.

* Composite/AIGLX must allow indiviual access to the "left" and 
"right" drawables, so that compositing windowmanagers can properly 
render stereoscopic windows.

* GLX/OpenGL quadbuffer stereo visuals shall only be supported on 
dual/stereo drawables.

* A extension of GLX PBuffers for stereo is not neccesary. The whole 
glDrawBuffer(GL_{FRONT|BACK}_{LEFT|RIGHT}); thing is only neccesary 
for the final display. In intermediate rendering stages there's no 
difference if one would pull separate left/right images from a PBuffer 
into distinct textures, or pull it from separate PBuffers or 
individual rendering passes.

* With the advent of steroscopic/3D material to the consumer market 
(first 3D Blu-Ray can be pre-ordered on Amazon right now), it might be 
neccesary to extend Xv to reflect that, though I think it should be 
covered if one can address "dual/stereo" sub-/drawables for Xv ports.

Of course this will also require some changes on the driver side. 
There are a couple of options how to implement stereo physically:
- Taking multiple outputs and join them into a stereo pair.
- Interlacing left and right into rows or columns. 
- Overly large monitors, display left and right side by side or on top 
of each other. A gap between them might be neccesary. On-Top + Gap is 
the Frame Packing format defined for HDMI1.4 / 3D Blu-Ray.
- Swapping left/right frame with each VSync, used with either shutter 
glasses or by displays with internal buffer.

I think X.Org eventually should define a standard set of options for 
configuring those above, to prevent having each driver have it's own 
set of options ending up in a mess of redundant, but not 
interchangible configuration tokens. I also think the same goes with 
the existing multimonitor setups, beyond multiple screens. I know that 
the whole multimonitor stuff is quite a mess, but eventually this 
issue should be cleaned up.

That's why I'd like to see stereo being properly specified in the 
first place, even if it's X.Org only, and a "proprietary" extension.


Wolfgang