Re: [AD] Oddity in src/linux/fbcon.c

[Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx>]

On 2003-09-13, Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:
> So FBIOGET_VBLANK is not defined on your system? Or maybe
> vblank_flags is zero, so Allegro must resort to the timer kludge
> to synchronize?

There's a lot of history about FBIOGET_VBLANK. It all started a
rainy day... I suck writing, so read this instead:

 http://www.mail-archive.com/linux-fbdev@xxxxxxxxxx

This happened several years ago, when I was still using some 2.2.x
kernel and an Matrox G200. Shawn's patch really improved page
flipping, but it wasn't accepted because a user space program could
potentially DOS the machine polling inside an infinite loop.

However, now I'm using a G450 and if I check
.../linux-2.4.20/drivers/video/matrox/matroxfb_base.c, the new
driver mentions Shawn's ideas as useful, so maybe they implemented
it. In fact, the archives mention that I was getting 35fps without
the patch. Now, with an unpatched kernel I get 60 with 800x600 page
flipping, sometimes going to 59 or 61. This probably means:

- Matrox has cool video hardware, maybe G450 doesn't need vsyncing.
- The new kernel has a workaround for that polling flaw which works
  without compromising the system.
- All of the above?

So I wouldn't worry about that code, it worked in the past, and
keeps working ok (at least for me :).

> In either case, your test shows that the second fb_vsync()
> probably makes a difference, so I think we should keep it. And
> add a comment that records what you've found.

I'm not very sure about the difference I got, if *really*
any. Besides, here's the info from the horse's mouth:

On 2003-09-13, George Foot wrote:
> Heh.  I didn't have much input to that driver really, but I just
> asked Shawn; it still took him a good ten minutes looking at the
> code to figure out what it was for!
> 
> The code is correct as it stands; the #ifdef/if/#endif lines
> are really saying "do we *not* have reliable vsyncing?" -- i.e.,
> if the kernel doesn't support it, or if the kernel does but the
> driver doesn't, then we do a second vsync.
> 
> The reason for this (Shawn was really happy when he remembered!) is
> that on a lot of graphics hardware the scroll registers don't
> take effect until the start of the next frame, so when you do a
> scroll you want to make sure you've waited at least until then.
> If you have reliable vsyncing, one call to vysnc is enough,
> but if you don't then the first call waits some time between 0
> and 1/60th of a second, and since it's not really synced to the
> retrace, this may or may not include an actual retrace.  However,
> by making a second call, we then wait for a full 1/60th of a second
> after the first call, and this is sure to include a retrace,
> assuming the refresh rate is at least 60Hz.  Sometimes overall
> we'll have waited past two retraces, or even more if the refresh
> rate is much higher than the fake vblank timer frequency, but
> it's still better than sometimes missing the retrace completely.
> 
> It might be worth putting a comment in the code explaining some
> of this. :)