Re: [Bino-list] Bino with Nvidia Vision 3D on Linux

[Florian Schulte]

Hello,

many thanks for your reply! In the meantime i finally got HDMI to work
with 120Hz after some modification of the edid file. Unfortunatly this
has changed nothing, the only thing i know now is that its not related
to some kind of VGA singal processing delay.

2013/1/11 Frédéric Devernay <address@hidden>:
> Very interesting.
>
> I have a few comments, and I don't know if they make sense:
>
> - google for an article called "The compatibility of consumer DLP projectors 
> with time-sequential stereoscopic 3D visualisation"
> by Andrew Woods and T Rourke. This will explain more about these issues. 
> Maybe we could link to it in the Bino FAQ or documentation.

I found this paper and it was very interesting to read but i think the
beamer itself should be fast enough because it runs at 120Hz and the
whole thing is working on windows. The beamer also has a special 3D
Vision option. When this is turned on, i get warnings not to use this
mode when displaying 2d content. I assume that this is because the dlp
color wheel runs at a higher speed and as a consequence the wear might
be higher. When i switch off this mode during bino is playing, the
image is not violett anymore all the time, but cycles through the
colors rapidly. Nevertheless the paper was helpful because there is a
graphic that shows the order of the colors projected.

>
> - when using VGA input, the projector must have received the whole image 
> before being able to project the first channel, but the vblank is signalled 
> at the beginning of the image. In the above article, check "Table 3: Time 
> offset for consumer DLP projectors found to be compatible with 60Hz and/or 
> 85Hz VGA time-sequential stereoscopic display." There is a lot of variation 
> between projectors. That may explain the mis-synchronization.
>
> - I didn't find such a delay anywhere in libnvstusb.  I would maybe put the 
> delay as a nanosleep() in nvstusb_set_eye before sending the data to USB, and 
> a separate thread would be better to do so (so that we don't miss the next 
> vblank even if the delay is large).
>
This is exactly what i've done before i wrote the first mail. I use
libnvstusbs stereo thread which basically waits for the vsync and then
shutters the glasses. I even made the delay variable to be able to
adjust it with the small control wheel on the emitter, but it didn't
help :( .
My next approach was to have two threads running, the first one writes
the current nanotime to a variable on vblank and the other computes
the time for the next shutter ( + delay ) and nanosleeps until then.
This way i was able to use negative delays to trigger the glasses
before the vblank. But i think i confused something yesterday because
i got negative sleep times.


> - maybe your projector has a setting for image delay/time offset?
>

unfortunately not

>
>
> fred
>

I will keep on trying.

Kind Regards
Florian