Do you have any suggestion to do this without 3d surround?

HI, magestik. I'm also working on a 3d video player based on 3d vision.

http://www.dhgate.com/mp102-dvi-dual-channel-projector-hardware/p-ff808081289b2c6f01289f4361144158.html
http://www.widescreengamingforum.com/fo ... 65&t=18394
plus you should hack into fullHD pj's, to add LED lightning (uniformity, aging), and 120hz
viewtopic.php?f=26&t=11344&p=50452#p50452

What you want to do is very different from what I do.

First, you want to do it for Windows. Then, you use the DirectX API (on Linux there is no API so we have to make it). Finally, I didn't start my video player yet.

Sorry I can't help you

For those who read this thread, kunguz managed to activate his glasses at 65 Hz (and syncrhonize them with his screen). We are going to start the daemon !

The one you recommend does not support 120hz on high resolution, either.

On linux, NV uses opengl quad buffer which Geforce does not support. I think your job is pretty tough.

This topic (and libnvstusb) has been created to control Nvidia 3D Glasses on Linux. My project, which is a fork, has the same goal. And it's working on any graphic card

somebody knows where can i find the file usbdi.h?

i can´t compile the project without it.

thanks!!

Last night, drawing inspiration from Kolrabi's code, and some quality time with a USB sniffer, I got our 3d vision glasses working on a Mac.

Rock solid 120Hz on a recent Viewsonic projector (PDJ6251), very little ghosting, no glitches, HDMI. This Viewsonic has two 120Hz 3d modes — the contrast ratio trashing "DLP-link" mode and a almost transparent "3d vision" mode. But the projector itself has not yet been "whitelisted" by Nvidia's drivers which, for me, was just the last straw.

I'll try to write this up properly soon, but some key facts for likeminded hackers:

1) I know hardly anything about the current state of OpenGL on Linux, but I suspect that the route being pursued here in this forum to sync the buffer swap to the glasses might be a bit of a dead end. I don't think there's any contemporary hardware on which you can say anything about how long it's going to take between a GLUT or a window system swap call and when your back buffer actually ends up as photons.

2) On the mac the solution is straightforward — we can busy loop on CGDisplayBeamPosition to pick the spot to swap (note: CGDisplayWaitForBeamPositionOutsideLines seems to be completely decoy, it returns instantly). The brute force approach of course takes most of a core, but it does give you a completely independent program that you can run in the background sending sync out while you start and stop various opengl programs (you have a 50% chance of having the eyes flipped at the start). Of course, being a little smarter about sleeping at the right time will reduce the CPU usage of this approach.

3) Like Kolrabi's code I'm currently using '0' as the offset in the eye switching packet since I can't compute any better value and I don't seem to need to. Staring closely at the USB dump it appears that both the left and right eye signals are being sent with no delay in between them, and then, around 16ms later the same thing happens. Here the offset is clearly required. In my code, I'm sending left and right with an 8.333ms delay between each.

4) It appears that all of the recent "real" graphics cards on Mac's support genuine quad buffered stereo that would appear to work with this technique without inserting additional FBO's into your code's swap routines. All in all, it seems like OS X + 3d vision is an ideal home-brew stereo hacking platform.

5) But I was unable to use Kolrabi's firmware extractor to extract the firmware from nvstusb.sys — either the most recent version or 190.62. It doesn't locate the right spot in the .sys file to make the extraction. Right now I'm booting into bootcamp once — this gets the "green light" on the unit and then rebooting into OS X. As long as the device isn't unplugged it stays useable. Of course, this means that you need to be able to install 3d vision on a windows partition in the first place, so short of illegally distributing the firmware file, ATI users remain out of luck. If it wasn't for that, I imagine it would work just fine on those cards as well.

6) And I needed a different set of magic timing numbers from Kolrabi (different from both sets that they included). The original set inside that code cause both shutters of my glasses to turn almost completely opaque (I can see a little color from the color wheel of my projector phasing in and out). The "correct" set is easily sniffed from the USB exchange that happens when you enter the "medical test image" from the 3d vision control panel. But I'm no closer to understanding the timing formulae — I have it working at 120Hz (actually 119.96Hz) and that's that.

7) Multi-screen stereo is a no-go since the clocks out of both ports of the cards we've tested have an arbitrary phase offset. If you are feeling up to it, you can check and uncheck "mirror displays" until you happen to get them close enough (you can call CGDisplayBeamPosition to find out). That can actually be automated, but seems like a ridiculous solution.

We're going to continue testing the setup here — including purchasing a new transmitter, just to make sure that there aren't multiple versions of this hardware out there (ours is from December).

In any case, it's working and working well — comparable, albeit on a far smaller scale, to our experiences working with high end digital cinema projectors and XPand x101's. It has far better contrast ratio than the XPanD x102's with consumer DLP-Link on the projectors I've tested.

It's probably time to set up a group & repository somewhere to formalize this project, no?