[MPlayer-users] New tdfxfb driver

Arpi arpi at thot.banki.hu
Sun Mar 31 00:01:02 CET 2002


> > maybe the same *4 width bug?
> Yes. I see the OSD stuff twice, in wierd colours, at half size, looks like i
> t's
> not getting drawn to YUV memory properly (it's wierd, see below).

maybe you call wrong osd renderer func?

> > > - Find DRI heissenbug
> > 
> > your get_image() should either refuse request with IMGFLAG_ACCEPT_WIDTH
> > or handle it (set mpi->width)
> Um, it does:
>                 if(!(mpi->flags & (MP_IMGFLAG_ACCEPT_STRIDE | MP_IMGFLAG_ACC
>                         return VO_FALSE;
> As you did in the mga driver.

but i handle mpi->width in mga driver while you removed that part...

note the ! in the if() above. it will return FALSE when neither

setting mpi->width is anyway mandatory for direct rendering.

> > you should use mem2agpcpy() to copy to video memory - it's faster than mem
> cpy()
> > (optimized for sysram->agpram transfer)
> Dunno if they made AGP banshees, I think so, but mine is PCI.

anyway try that code, it's from sysram->videoram copy, may help on pci
too... you know, agp is just a faster pci slot

> > what is the format of planar yv12 image in the agp memory?
> > it seems (but seems to be weird to me):
> 3 separate memory areas, one for Y, one for U and one for V. (fb_YUV->[YUV]
> point to different areas, we just poke them in at the same time. Each line t
> akes
> 2048 bytes (VOODOO_YUV_STRIDE) which is why we have to do all that increment
> al
> magic stuff...)

then it's better to copy the 3 planes in 3 for() instead of one, for cache

> Another thing I added to my todo is get the screen blanking working properly
> , I
> think I know how to do this properly.
yes, using double buffering :)

> I've been hacking a little more on the code, latest version is up at:
> http://pkl.net/~mark/vo_tdfxfb.c

A'rpi / Astral & ESP-team

Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu

More information about the MPlayer-users mailing list