DirectFB - Home of the pragmatist Roadmap

[directfb-users] Re: WAITFORSYNC sleeps too long
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-users] Re: WAITFORSYNC sleeps too long

On Sat, Jan 15, 2005 at 02:50:30PM +0100, Jan Gukelberger wrote:
> Hi,
> we have a strange problem on one of our development machines:
> Our graphics application should sync with monitor frequency by calling
> IDirectFB::Flip( WAITFORSYNC ). On this particular machine, however, the
> flip takes almost exactly 113 ms for every frame, while it should be
> 13ms (fbset reports 75 Hz, see attached output).
> Graphics hardware is a Matrox G550, the same as in my setup where the
> application works without problems.
> I have digged DFB and matroxfb sources a bit and built the following
> theory:
> IDirectFB::Flip() indirectly calls fbdev.c::primaryWaitVSync() which
> does 
>      if (ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC, &zero ))
>           waitretrace();
> In matroxfb, the ioctl waits with
>      wait_event_interruptible_timeout(vs->wait, cnt != vs->cnt, HZ/10)
> for the VSYNC interrupt, but times out after HZ/10=100ms, so -ETIMEDOUT
> is returned to primaryWaitVSync() which calls waitretrace() which, in
> turn, does a busy wait for the next VSYNC and consumes 1/framerate=13ms.
> This would more or less explain the constant frame length of 113ms.
> Now, the question is: Does this explanation sound plausible and, if yes:

Sounds plausible to me. Obviously it should be quite easy to verify that 
by checking the return value from the ioctl.

> Why does the wait_event_bla fail? Isn't there any VSYNC interrupt? How
> can this happen? 

Obviously the first thing to check is if your kernel actually supports 

Secondly make sure the graphics card actually has an irq assigned to it. 
BIOS usually has an option for it. lspci should tell you if the irq is 

If everything checks out the next step would probably adding some debug 
printks to the kernel to see what happens. One thing that might be the 
cause is some irq routing problem (ACPI related maybe).

> I've got no idea of where this interrupt should normally come from, but
> could this be caused by a second PCI graphics board in the machine, on
> which an Xserver runs?

I doubt that should cause any problems unless the Xserver is told 
to touch the G550. Or maybe the Xserver is stupid an pokes at some 
VGA ports while shouldn't. Which card is inited by the BIOS?

If someone actually disables the interrupt you should see a message from 
matroxfb with dmesg.

Ville Syrjälä

Home | Main Index | Thread Index / Development / Old Archives