> > There is one subtlety: when Flip() is called, the Matrox > > implementation checks that the bottom field is active before flipping > > the buffers, waiting if necessary. > > So we have 50 interrupts per second.
Yes. > > The Unichrome implementation can't > > make that check (the hardware can't tell you which field it's on) so > > it's forced to blindly wait for the interrupt that occurs at the start > > of the bottom field. > > If we don't know which field is currently active (displayed), how is it > possible to determin the interrupt which starts the bottom field ? DirectFB doesn't know. The kernel framebuffer _does_ know because it counts interrupts since reset. There's an extended ioctl to wait for a particular field but no API by which DirectFB can check the current field without waiting. That's what causes the slight difference in the timing that I was referring to. I could add an ioctl to check the current field and make the DirectFB driver behave more like the Matrox one. However, doing that would introduce a potential race condition (which may exist in the Matrox case too). The real solution to all this is the combined flip/wait ioctl but that's a future enhancement. > If the field cannot be determined, it is pure luck if we display the > correct field order. If something other happens (loosing an interrupt) > we are on the wrong one (or right one back). No, as I say, the flip will always happen on the correct field because the kernel framebuffer keeps track. Losing an interrupt could result only from a kernel interrupt latency exceeding 1/50th second and if that happens I think all bets are off. I have it working 100% reliably with a xine-derived video player, regardless of what else is going on on the machine. Mark _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
