From owner-freebsd-multimedia Tue Feb 11 20:28:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA22373 for multimedia-outgoing; Tue, 11 Feb 1997 20:28:30 -0800 (PST) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA22356 for ; Tue, 11 Feb 1997 20:28:24 -0800 (PST) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 11 Feb 1997 23:27:53 -0500 (EST) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA08750; Tue, 11 Feb 97 23:27:51 EST Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id XAA15951; Tue, 11 Feb 1997 23:25:49 -0500 Message-Id: <19970211232548.58351@ct.picker.com> Date: Tue, 11 Feb 1997 23:25:48 -0500 From: Randall Hopper To: multimedia@freebsd.org Cc: Amancio Hasty Subject: Bt848 driver & Wincast -- some success Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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) 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. 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. 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? 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'm thinking of memcpying the data out of the mmap buffer before 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. 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 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