Date: Tue, 11 Feb 1997 23:25:48 -0500 From: Randall Hopper <rhh@ct.picker.com> To: multimedia@freebsd.org Cc: Amancio Hasty <hasty@rah.star-gate.com> Subject: Bt848 driver & Wincast -- some success Message-ID: <19970211232548.58351@ct.picker.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970211232548.58351>