Date: Tue, 11 Feb 1997 21:04:23 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randall Hopper <rhh@ct.picker.com> Cc: multimedia@freebsd.org Subject: Re: Bt848 driver & Wincast -- some success Message-ID: <199702120504.VAA26988@rah.star-gate.com> In-Reply-To: Your message of "Tue, 11 Feb 1997 23:25:48 EST." <19970211232548.58351@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, You need the B848 Databook from Brooktree if you want to hack on the driver, period. What is your CPU and motherboard chipset, example Natoma or Triton... If you have a Mercury chipset, then you don't have enough PCI bandwith to drive a 640x480 32bits picture. Also try playing with the PCI parameters in your BIOS. Your PCI clock rate should be around 32 or so and not 60 or higher. You can try 320x240 with something like 15bits or 8bits color depth. The ghostimage that you are experiencing in your system is an indication that your PCI chipset is not able to keep up with the Bt848. The driver does not have the ioctls to transfer video to memory and is not hard to add . I can provide this feature before the end of the week;however, if you want to take advantage of this feature then you will have to ask the XFree86 team or peruse thru their release notes for an appropiate video card which supports linear frame buffering. >From The Desk Of Randall Hopper : > Got the latest Bt848 driver linked into 2.2-ALPHA this evening and had > some success with Luigi's 8-bit TV on the new Wincast TV/dbx. I got sound > and the 320x240 image was updating at a reasonable speed, but only the even > scan lines (or frames) were updating with every refresh. The odd scan > lines (or frames) seemed to update somewhat randomly with a frequency of > 1-10 seconds, giving the image a strange ghosting look to it. > > I could still easily see the effect when I beefed the size up to > 640x480. It was much less prominent though if I ran xmag or some program > that dogged the X server, slowing down the frame rate. > > I haven't looked at the driver code yet so I don't know what all the > ioctls do, but does this: > > i = METEOR_CAP_SINGLE ; /* buffer up 1 frame */ > ioctl(video, METEORCAPTUR, &i) the driver captures a single frame buffer that is the Bt848 dmas to the system memory a single frame then it stops. If you are capturing even and odd frame fields then the Bt848 first burst the ODD frame skipping every other line and then the EVEN frame field gets overlay every other line. This is the pattern: 0 even line 1 odd line 2 even line 3 odd line etc... > > start assembling a single "frame" into the mmap driver buffer (as the > comment suggests), or a single "image" (2 adjacent frames). I'm guessing > its the former and I think that would explain the behavior I'm seeing. If > the CAP_SINGLE submissions were just happening to coincide closely with the > 2x the frame rate, I'd only be getting one frame updated most of the time. See my previous comment about DMA transfers. A dirty of eliminating the ghost image is to drop down to 320x240 and capturing either EVEN or ODD fields. > I flipped into CONTINUOUS mode, and though that got rid of the > odd-frame ghosting, but now there was dancing noise in the image. I guess > this might be because TV's reading while the driver's writing into the > buffer. Yes, this could be an artifact of capturing video and with a slow access to a video frame buffer. > Question: what happens when a CAP_SINGLE is sent to the driver when > the previous CAP_SINGLE is still running. Is it queued or ignored? Nothing. The ioctl is ignored. > > Gotta hang it up for this evening. If anyone has suggestions of > things I should try next to improve my "reception", please send e-mail. I will look further into the error recovery of the driver and see how can I improve on it. > I'm thinking of memcpying the data out of the mmap buffer before Nope, because the driver is continously updating the frame once it has been initially fire up. > processing; maybe that'll clear up some of the static in a CONTINUOUS run. > Alternatively, is there a "capture two adjacent frames" function (something > like a CAP_DOUBLE) in the bktr driver? That'd be useful. Also, is there > any asynchronous notification from the driver when a frame has been > assembled. There is no buffering of frames at the driver level at this time . It is tricky to do with the Bt848 because one will have to write a Bt848 program to capture two consecutive or N frames. The Bt848 differs from the SAA 7196 by way that the DMA controller is controlled by a "Risc Program" which resides in the host memory and the "Risc Program" has the address for each line of where it has to burst the data to and there no indirect register capability for the Bt848 chipset. Yes, there is asynch notification via signals . > After trying that, I'll look at getting the 15-/24-bit TV working in > the 16-/32-bit modes my card supports. From what little I've looked at the > code, I think this is just be a matter of shuffling the RGB bits when > building the image. > > Another question. Does the bktr driver support bus-mastered DMA > straight to the video card memory if it supports linear addressing? I > think you mentioned that TV doesn't use this capability now, but I wasn't There is a version an old one called dtv which supports direct transfer to the vga's buffer. I will be happy to report back on how well does it work with the Bt848 later on this week. > clear as to whether the device driver supported that or not. > > Thanks for the driver Amancio, for the TV updates Luigi, and for the > help getting started. > > Randall Have fun and be happy, Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702120504.VAA26988>