Re: [AD] 4.0.2 release

[George Foot <gfoot@xxxxxxxxxx>]

On Thu, Jun 13, 2002 at 02:24:18PM +0100, Laurence Withers wrote:
> Current fbdev implementations of 'vsync()' cause busy waiting *in the 
> kernel* -- this cannot be preempted, and so no other apps get the CPU 
> between a call to vsync() and the next retrace, at which point the CPU 
> must be given back to the app calling vsync() because that is the whole 
> point of waiting for the retrace!

I think things have changed a bit.  The current kernel does have
a lot of support for vsyncing, some how Shawn wrote it and some
with a different API.  There are several ways to check for
vsyncs (e.g. detecting the vsync period, reading the scanline
counter, reading the total number of vsyncs since startup) and
not all of these are available on all hardware.

Allegro supports some of the currently implemented fbdev syncing
methods (either they put in Shawn's API exactly or we already
fixed Allegro to support the new API) but not others -- it may
be worth extending the capabilities of Allegro's driver to the
new fbdev syncing methods, since different hardware will provide
different options.  On my Matrox G200 I get proper syncing with
the existing methods.  (I think Shawn was using a Matrox card
when he made them in the first place, so that's not surprising!)

There's some code at the top of Allegro's fbdev.c to define the
"sticky" mode if it's not already defined, since it's not
present in Linux 2.4 and up; perhaps we should deprecate that
code, if sticky mode was only ever available with Shawn's
patched kernel (which is dead really).

For reference I pasted some of Linux 2.4ish's fb.h below.
Allegro uses FB_VBLANK_HAVE_VBLANK as a last resort, preferring
FB_VBLANK_HAVE_STICKY (defunct) or FB_VBLANK_HAVE_VCOUNT.  At a
glance we should be able to support FB_VBLANK_HAVE_COUNT
usefully, though I can't test this as the matrox fb driver
doesn't support it.  I'd guess the "count" field just counts
the vblanks since startup or something.

I don't know what the last two options are, or how
they differ from HAVE_VBLANK and VBLANKING.  The Matrox fb
driver in the kernel supports HAVE_VSYNC too, though I'm not
sure how it works; the matrox fb driver sets the VSYNCING bit
according to a status bit read from the card, so it's presumably
much like polling VGA's vsync register.  Which means it
basically works like HAVE_VBLANK. :)  (and I just found a bug in
the kernel's matrox fb driver...)

Since I've got some time off work now, I may implement some of
these things.  But as I said, I can't test the retrace count
method because it's not provided by the matrox fb driver.

George


#define FB_VBLANK_VBLANKING 0x001   /* currently in a vertical blank */
#define FB_VBLANK_HBLANKING 0x002   /* currently in a horizontal blank */
#define FB_VBLANK_HAVE_VBLANK   0x004   /* vertical blanks can be detected */
#define FB_VBLANK_HAVE_HBLANK   0x008   /* horizontal blanks can be detected */
#define FB_VBLANK_HAVE_COUNT    0x010   /* global retrace counter is available */
#define FB_VBLANK_HAVE_VCOUNT   0x020   /* the vcount field is valid */
#define FB_VBLANK_HAVE_HCOUNT   0x040   /* the hcount field is valid */
#define FB_VBLANK_VSYNCING  0x080   /* currently in a vsync */
#define FB_VBLANK_HAVE_VSYNC    0x100   /* verical syncs can be detected */

struct fb_vblank {
    __u32 flags;            /* FB_VBLANK flags */
    __u32 count;            /* counter of retraces since boot */
    __u32 vcount;           /* current scanline position */
    __u32 hcount;           /* current scandot position */
    __u32 reserved[4];      /* reserved for future compatibility */
};