[MPlayer-G2-dev] Fwd: Re: 2.4.20 matrox_crtc2.c bug (ioctl FBIOPAN_DISPLAY)

[Arpi]

--------- Forwarded message ---------
From: "Petr Vandrovec" <VANDROVE at vc.cvut.cz>
To: Arpi <arpi at thot.banki.hu>
Subject: Re: 2.4.20 matrox_crtc2.c bug (ioctl FBIOPAN_DISPLAY)

On 24 Jul 03 at 3:49, Arpi wrote:
> >         return -EINVAL;
> >   if (con == m2info->currcon)
> >      matroxfb_dh_pan_var(m2info, var);
> >   dsp->var.xoffset = var->xoffset;
> >   dsp->var.yoffset = var->yoffset;
> > 
> > like driver does everywhere else.
> 
> :)
> 
> I assume you'll submit this patch to mainstream kernel...

Maybe...
 
> > For 2.6.x you can do FBIO_WAITFORVSYNC ioctl, as I finally took Syrjala's
> > patch, extended it to handle both CRTC and put into the driver.
> 
> I know his patch, but it makes apps blocking until vsync arrives.
> It may work for multithreaded apps (blocking only the display thread),
> but for mpalyer (which runs in single thread) it's just eating cpu :(

if (!fork()) { ioctl(FBIO_WAITFORVSYNC); ioctl(FBIO_PANDISPLAY); exit(0) ;-)
I'm not sure how fast it is...

> > Supporting FB_ACTIVATE_VBL for setting videomode is impossible (due to 
> > connection to the tty subsystem), but if you can find somewhere (or if 
> > you can persuade me that API author thought it that way)
> > that FB_ACTIVATE_VBL should be looked at for panning too, then it is
> > definitely (very) simple to extend 2.6.x matroxfb to do that.
> 
> The strange thing is, that both vidmode setting and panning behaves like
> FB_ACTIVATE_VBL set for crtc2, and behaves like FB_ACTIVATE_VBL unset
> for crtc1. I gues sit's only a (or a few) bits in register programming,
> i'll try to find it when i re-read g400 register docs for crtc2 yuv support.

page 4-75, CRTC1:

When accessing the three-part startadd field, the portion which is located in
CRTCEXT0 must always be written; it must always be written after the other
portions of startadd, which are located in CRTCC and CRTCD). The change of
start address will take effect at the beginning of the next horizontal
retrace following
the write to CRTCEXT0. Display will continue at the next line, using the new
startadd value. This arrangement permits page flipping at any line, with
no tearing
occurring within the line.

To avoid tearing between lines within a frame, software can poll either
vcount or the vretrace
field of INSTS1, or use the VSYNC interrupt to update CRTCEXT0 between frames.

page 4-143, CRTC2:

All the addresses programmed in the 2nd CRTC address generator must be
aligned on an 8 quadword
boundary (the 6 LSBs set to '000000'). All these address registers are
double-buffered. This means that,
the addresses written in these registers become effective after the
beginning of the next vertical blank. At
this point, the programming values written during the drawing of a frame
will only affect the next frame,
therefore, no tearing occurs.


So CRTC1 reloads address at the end of line, CRTC2 at the end of frame.
No way around it for CRTC2, but we can emulate VBL reload for CRTC1. I'll
do that. More work :-(
                                            Petr