Date: Mon, 18 Dec 1995 15:59:34 -0600 From: Jim Lowe <james@miller.cs.uwm.edu> To: luigi@labinfo.iet.unipi.it Cc: hackers@freebsd.org, tinguely@plains.nodak.edu Subject: Re: meteor driver bug Message-ID: <199512182159.PAA06086@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> > Subject: meteor driver bug > To: james@miller.cs.uwm.edu (Jim Lowe) > Date: Sat, 16 Dec 1995 16:26:30 +0100 (MET) > Cc: tinguely@plains.nodak.edu, hackers@freebsd.org > ******************** meteor.c [driver] ******************************** > > BUG: around line 1072 of the driver, the following code: > > *p++ = buf; /* even y or even RGB */ > /* set end of buffer location */ > *(p+36) = *(p+35) = buf + mtr->alloc_pages * PAGE_SIZE; > > the last line should read > > *(p+34) = *(p+35) = buf + mtr->alloc_pages * PAGE_SIZE; > > as the pointer (p) has been already incremented. Due to this > bug, we are going to write past the end of the 7116 registers, > with unknown effects. Hmmm... By my count there are 38 4 byte registers and we want to offset to dma end (even) and dma end (odd), which would be +36 & +37. Since we increment, then we want 35 & 36... I will count again, but I think this code is correct. > > > FEATURE: at offset 0x3c in the 7116, it would be preferable to > set the "Field Toggle" bit. This enables the 7116 to simulate the > presence of an interlaced image even with non-interlaced images. It > should help with VTRs and should not harm otherwise. Thus I would > change the init value from > > /* 0x3c */ 0x00000103, /* 9:8 *RW Reserved (0x0) > > to > > /* 0x3c */ 0x00000107, /* 9:8 *RW Reserved (0x0) I am not sure what this does exactly, maybe Mark can comment. I don't think there would be any problem with this. > > FEATURE: the 'correct' values for regs 01-05 of the 7196, > according to the data sheets, should be the following: > > /* 01 */ 0x30, /* 7:0 Horizontal Sync Begin for 50hz */ > /* 02 */ 0x00, /* 7:0 Horizontal Sync Stop for 50hz */ > /* 03 */ 0xe8, /* 7:0 Horizontal Sync Clamp Start for 50hz */ > /* 04 */ 0xb6, /* 7:0 Horizontal Sync Clamp Stop for 50hz */ > /* 05 */ 0xf4, /* 7:0 Horizontal Sync Start after PH1 for 50hz */ > > I tried them with a 50Hz PAL camera, and they seem to work fine. > They could replace my previous suggestion. I am not sure what you mean by correct. If you go by CCIR-601, then the values that are in the driver are correct (see pp 2-18 of the Desktop Video Data Handbook by Phillips). I know this is what the default values for these are for the 7196, but I don't beleive these are CCIR-601 values. > > > PROPOSAL: whith moving images, mixing samples from two frames produces > a very unpleasant visual effect (basically, one frame is shifted > with respect to the previous one). Moreover, this mix produces > (spatial) high frequency components which make the compression > algorithms work less efficiently. My proposal is to acquire > single frames by default, and use both frames only in the case > of the highest resolution images (e.g. 640x480 or 768x576). > This can be done without loss of resolution. It requires some > simple changes to the METEORSETGEO ioctl, and possibly to > the interrupt handling routine. > I always thought it took two Fields before one had a complete Frame. The card should be able to capture 60 fields/sec or 30 frames/sec in ntsc or 50 fields/sec or 25 frames/sec in pal. I beleive the driver captures two fields for each frame. I am not sure what you are proposing here -- but maybe it is a terminology issue that I am missing... -Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512182159.PAA06086>