How are you "turning on the vertical sync", out of curiosity?
Have you bothered to check the return value of poll() in your test program, so you know whether it returns because the conditions are met, or because of an error in the parameters? $20 says it's returning a negative value, and setting errno to EBADF (no, this isn't actually any kind of wager, but you understand what I'm trying to get across, don't you?)...
A simple check for error would be to find out if the return value is less than zero, and if so, call perror("poll"); or something similar. And a check of the manpage for poll would tell you what the specific error value you're getting, if any, means. You may also find the select() syscall's manpage helpful. The reason I'm thinking about negative return values is that it looks like your file descriptor is invalid when you call poll() -- you should call open() first.
You're also calling poll() with the "event to poll for" field set to (unsigned short)-1. Why? Again according to the manpage, the only valid values are currently 1, 2, and 4, or sums of those (so in other words, the only valid bits that can be set are bits 0, 1, and 2, and you're setting all bits up to 15). I therefore also wouldn't be surprised if it's returning with an error because you're passing an invalid set of events to wait for...
Even if you can get these issues resolved and the poll() syscall does then work, there's no guarantee that it will in the future. As far as I (as a non-nVidia person) am concerned, the nvidia* device file interface is and should be completely opaque; in other words, there's nothing stopping nVidia from changing this behavior at will and then changing their OpenGL driver (libGL.so.<version> and the matching gl* and glX* functions) to match, in the future. A better solution than poll()ing the device file would be using the OpenGL library to wait for vsync for you, by using a flag or a shell variable on the OpenGL function call that does the displaying (like glXSwapBuffers()'s default behavior with no special flags or shell setup, for example). That way, you would always be waiting for retrace (unless the __GL_SYNC_TO_VBLANK shell environment variable isn't set; take a look at the nVidia README file, in the section regarding the SYNC_TO_VBLANK shell variable for more info).
In other words, to make a long post slightly shorter, I think you should be enabling vblank by using the __GL_SYNC_TO_VBLANK shell variable (and perhaps a setenv() in your program, if you absolutely can't live with the user's setting and have to make it override the user's preferences -- generally not a good idea in the land of Unix, but it would work), and the glXSwapBuffers function. If you are doing both of those things, and it isn't working, only then would I start to report bugs, as millions of other people (or so) are using these drivers and those environment variables, and aren't complaining. It goes along with part of ESR's "How to Ask Questions" paper -- it is possible that you're the only one that's using the drivers and env. variables that way, and therefore the only person that's seeing these problems, but it's about a thousand to one chance. So yeah -- I'm asking if this is the way you're doing it or not.
Last edited by bwkaz; 11-09-02 at 03:57 PM.