bug in matrox fb vsync code

bug in matrox fb vsync code

Post by George Foo » Sat, 15 Jun 2002 08:50:06




the domain does not resolve.

I'm using kernel 2.4.18, and noticed a bug in the matrox vsync
code...  Here's drivers/video/matrox/matroxfb_base.c from line
992 onwards:

    static int matroxfb_get_vblank(CPMINFO struct fb_vblank *vblank)
    {
        unsigned int sts1;

        memset(vblank, 0, sizeof(*vblank));
        vblank->flags = FB_VBLANK_HAVE_VCOUNT | FB_VBLANK_HAVE_VSYNC |
                FB_VBLANK_HAVE_VBLANK | FB_VBLANK_HAVE_HBLANK;
        sts1 = mga_inb(M_INSTS1);
        vblank->vcount = mga_inl(M_VCOUNT);
        /* BTW, on my PIII/450 with G400, reading M_INSTS1
           byte makes this call about 12% slower (1.70 vs. 2.05 us
           per ioctl()) */
        if (sts1 & 1)
            vblank->flags |= FB_VBLANK_HBLANKING;
        if (sts1 & 8)
            vblank->flags |= FB_VBLANK_VSYNCING;
****    if (vblank->count >= ACCESS_FBINFO(currcon_display)->var.yres)
            vblank->flags |= FB_VBLANK_VBLANKING;
        vblank->hcount = 0;
        vblank->count = 0;
        return 0;
    }

The line in question (marked ****) reads from vblank->count
which is zeroed by the memset and not changed since then.  I
believe it should be reading from vblank->vcount instead.

I'm sorry not to have checked whether this has been fixed; I
found that some Matrox bugs were fixed since 2.4.18 in the
2.4.19 prerelease changelog, but my Internet connection is only
a 56k modem so I can't afford to download either the prerelease
patch or the latest development branch.

I'd also be interested to know if there's any documentation of
the difference between VSYNC and VBLANK in the context of the
fbdev code -- I haven't found any references in the kernel
documentation, perhaps there's some resource online?

Thanks for your time,

George

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

bug in matrox fb vsync code

Post by Petr Vandrove » Sat, 15 Jun 2002 21:00:08




> the domain does not resolve.

>     static int matroxfb_get_vblank(CPMINFO struct fb_vblank *vblank)
>     {
>         unsigned int sts1;

>         memset(vblank, 0, sizeof(*vblank));
>         vblank->flags = FB_VBLANK_HAVE_VCOUNT | FB_VBLANK_HAVE_VSYNC |
>                 FB_VBLANK_HAVE_VBLANK | FB_VBLANK_HAVE_HBLANK;
>         sts1 = mga_inb(M_INSTS1);
>         vblank->vcount = mga_inl(M_VCOUNT);
>         /* BTW, on my PIII/450 with G400, reading M_INSTS1
>            byte makes this call about 12% slower (1.70 vs. 2.05 us
>            per ioctl()) */
>         if (sts1 & 1)
>             vblank->flags |= FB_VBLANK_HBLANKING;
>         if (sts1 & 8)
>             vblank->flags |= FB_VBLANK_VSYNCING;
> ****    if (vblank->count >= ACCESS_FBINFO(currcon_display)->var.yres)
>             vblank->flags |= FB_VBLANK_VBLANKING;

It should be vblank->vcount. It is fixed in mga-2.5.20-tvout.gz
at ftp://platan.vc.cvut.cz/pub/linux/matrox-latest. Obviously
this patch does not apply to 2.4.x.

Quote:> The line in question (marked ****) reads from vblank->count
> which is zeroed by the memset and not changed since then.  I
> believe it should be reading from vblank->vcount instead.

Yes.

Quote:> I'm sorry not to have checked whether this has been fixed; I
> found that some Matrox bugs were fixed since 2.4.18 in the
> 2.4.19 prerelease changelog, but my Internet connection is only
> a 56k modem so I can't afford to download either the prerelease
> patch or the latest development branch.

AFAIK it is not fixed even in latest 2.4.x prepatches.

Quote:> I'd also be interested to know if there's any documentation of
> the difference between VSYNC and VBLANK in the context of the
> fbdev code -- I haven't found any references in the kernel
> documentation, perhaps there's some resource online?

linux-fbdev.sourceforge.net maybe have some documentation.
I wrote implementation according to flags names...
                                        Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. +hsync +vsync works the same as -hsync -vsync : BAD !!!

Hi all,
 I have an old 14" monitor that supports up to 1024x768(interlaced) modes.
I use it with 640x480 mode with X but I would use it with 800x600 mode (as I
did with Win98). I hade problems under Win98 because of the Horizontal and
Vertical Synchronization. I had to use Powerstrip in order to set the -hsync
and +hsync (instead of the default +hsync and +vsync) to make the desktop
layout fit inside the monitor, otherwise It had been too small horizontally
and to wide vertically (out of the monitor). But with -hsync and -vsync the
desktop entered perfectly inseide the monitor display area (something
smaller, but entirely inside).

Powerstrip showed me the following infos:

Pixel Clock        36,908 Mhz

      Horizontal
Scan rate            36,043 Hz
Active                800px
Front Porch        48px
Sync Width        72px
Back Porch        104
Total                    1024

    Vertical
Scan rate            57,669 Hz
Active                600px
Front Porch        1px
Sync Width        2px
Back Porch        22
Total                    625

Then I set up XF86Config with the following modeline:
Modeline "800x600"    36    800    848    920    1024    600    601    623
625    -HSync    -VSync

X starts but as bad as the worng configuration with Win98 (too small
horizontally and to wide vertically).
It seems that X doesn't take in account th -hsync and -vsync; even if I
change them (both or singularly), I get the same distorted screen
resolution.

What's wrong with it??

I will be gratefull for any suggestion,
       Roberto

2. Transparent pixmaps

3. Matrox Millenium ; fixed frequency monitor ; vsync + hsync (fwd)

4. Enlightenment, minimized windows, Netscape, and me.

5. Matrox Millenium ; fixed frequency monitor ; vsync + hsync

6. ARP cache flush - INDUCED!

7. Matrox Mill II fb?

8. Some (not too brief) thoughts on the IHV problem

9. compile fix for matrox fb 2.5.2-9

10. no console messages after switch to FB (matrox)

11. no console messages after switch to FB (matrox

12. Matrox FB problem in latest 2.4.21-rc1-BK

13. Code fragments/plug-ins for solaris?