[MPlayer-dev-eng] [PATCH] nvidia_vid update

[Dmitry Baryshkov]

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>