[MPlayer-dev-eng] [PATCH] nvidia_vid update
Dmitry Baryshkov
mitya at school.ioffe.ru
Tue Jan 6 11:03:16 CET 2004
Hello,
On Mon, Jan 05, 2004 at 10:41:02PM +0100, Sascha Sommer wrote:
> > Hello,
> > Attached is a patch, that fixes panning & small issues with
> > multibuffering. Could you please test it. It works for me, but can;t
> > test on >=NV10, NV03 and in cvidix(still can't get it working on my
> > Vanta :( ), winvidix.
>
> What is the problem no output or garbled image?
> How do you use it?
No output (cvidix). And using it from simple text console (no FB, etc.).
If I start it with -vo cvidix and switch to X, all goes well.
BTW: looks, that some special initialization is missing (not tested
recently, but month or so ago I had following results):
X11 + nv driver -> works
X11 + nvidia driver -> works
X11 + vesa driver -> NOT
-vo vesa:vidix under pure console -> NOT
-vo vesa:vidix under fbdev -> works
-vo fbdev:vidix under VesaFB -> NOT
-vo fbdev:vidix under RivaFB -> works
I tried to figure out what is wrong, but failed.
Will retry after exams in university.
>
> > - unsigned int next_frame;
> > + unsigned int cur_frame;
>
> Looks like pure cosmetics. Is this really needed?
It's cosmetics :) But IMHO a bit of cosmetics is better, than next_frame
variable pointing to current frame and not to the next one.
>
> >-static void nv_waitidle(struct rivatv_info *info ){
> >+/*static void nv_waitidle(struct rivatv_info *info ){
> > while (info->chip.PGRAPH[0x1C0] & 1) {}
> > }
> >-
> >+*/
>
> This function can be removed.
OK.
>
>
> > static void nv_getscreenproperties(struct rivatv_info *info){
> > uint32_t bpp=0;
> > info->chip.lock(&info->chip, 0);
> > /*get screen depth*/
> > VID_WR08(info->chip.PCIO, 0x03D4,0x28);
> >- bpp = VID_RD08(info->chip.PCIO,0x03D5);
> >+ bpp = VID_RD08(info->chip.PCIO,0x03D5)&0x3;
>
> hm
According to nv4ref.h, only 2 last bits define bpp:
/* Controls what the format of the framebuffer is */
#define NV_PCRTC_PIXEL 0x28
#define NV_PCRTC_PIXEL_MODE 7:7
#define NV_PCRTC_PIXEL_MODE_TV 0x01
#define NV_PCRTC_PIXEL_MODE_VGA 0x00
#define NV_PCRTC_PIXEL_TV_MODE 6:6
#define NV_PCRTC_PIXEL_TV_MODE_NTSC 0x00
#define NV_PCRTC_PIXEL_TV_MODE_PAL 0x01
#define NV_PCRTC_PIXEL_TV_HORIZ_ADJUST 5:3
#define NV_PCRTC_PIXEL_FORMAT 1:0
#define NV_PCRTC_PIXEL_FORMAT_VGA 0x00
#define NV_PCRTC_PIXEL_FORMAT_8BPP 0x01
#define NV_PCRTC_PIXEL_FORMAT_16BPP 0x02
#define NV_PCRTC_PIXEL_FORMAT_32BPP 0x03
>
> > /* get 9th bit in CRTC_OVERFLOW*/
> > info->screen_y |= (VID_RD08(info->chip.PCIO,0x03D5) &0x02)<<7;
> > /* and the 10th in CRTC_OVERFLOW*/
> >+ VID_WR08(info->chip.PCIO,0x03D4,0x07);
>
> the register shouldn't change. Does it?
Just to be sure. At least it may change (multitasking :).
>
>
>
>
> >+ while (bps == 0)
> >+ {
> >+ if (info->chip.arch != NV_ARCH_03)
> >+ bps = info->chip.PGRAPH[0x00000670/4];
> >+ else
> >+ bps = info->chip.PGRAPH[0x00000650/4];
> >+// if (bps == 0) fprintf(stderr, "bps returned 0: %d\n");
> >+ }
> > x = info->wx - (pan % bps) * 8 / info->depth;
> > y = info->wy - (pan / bps);
> >+ }
> >+
>
> I'm currently unable to test it, but afair this register is also 0 in
> textmode.
Yes, but in text mode info->depth == 0, so the whole block is skipped.
--
With best wishes
Dmitry Baryshkov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20040106/e06ede03/attachment.pgp>
More information about the MPlayer-dev-eng
mailing list