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>
index | next in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970211232548.58351>