Date: Thu, 24 Apr 1997 20:48:58 -0400 From: Randall Hopper <rhh@ct.picker.com> To: multimedia@freebsd.org Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Amancio Hasty <hasty@rah.star-gate.com>, Steve Passe <smp@csn.net>, Doug White <dwhite@resnet.uoregon.edu> Subject: Updated driver (bt848-970424) Message-ID: <19970424204858.07591@ct.picker.com>
next in thread | raw e-mail | index | archive | help
New rev of fxtv (0.41) and the bt driver (970424) are available at:
http://multiverse.com/~rhh/fxtv
Steve, can you mirror the new driver off the multimedia home page?
(I'll detail the Fxtv changes in a separate message shortly--just so
this one doesn't get too huge.)
DRIVER UPDATE: bt848-970424
This is a merge of all the latest features:
- Amancio's clipping, frame sync, and frame base addr adjustment for
rows < CIF
- John-Mark's pixel FIFO byte/short swapping
- My enhanced pixel format I/F, w/ 565 16bpp and packed 24bpp (3Bpp)
support; also fixed ODD_ONLY CAP-SINGLEs and added CAP_SINGLE
failure cleanup
That's the summary.
For those that have worked on the driver, let me detail what I did a little
bit more. Everyone else probably won't be interested past this point.
1) ENHANCED PIXEL FORMAT INTERFACE
I integrated closely with John-Mark's byte/word swapping support to
form a simple interface that abstracts driver pixel format capabilities
from the app. Basically apps will:
a) Surf the supported pixmap formats via GSUPPIXFMT and pick one:
struct meteor_pixfmt pf;
for ( i = 0; ; i++ ) {
pf.index = i;
if ( ioctl( c->fd, METEORGSUPPIXFMT, &pf ) < 0 )
break;
/* Do I like this format? If so, break */
}
b) Set a pixmap format by index via SACTPIXFMT
c) The active format can be queried by index via GACTPIXFMT
While I was at it, I added support for 565 16bpp and packed 24bpp
so we could do direct-video TV in those video modes as well. This
was a pretty simple addition with the generic interface in place.
So the driver now supports these RGB pixel formats:
FMT Bpp Component Masks B,WSWAP
RGB, 2, { 0x7c00, 0x03e0, 0x001f }, 0,0
RGB, 2, { 0x7c00, 0x03e0, 0x001f }, 1,0
RGB, 2, { 0xf800, 0x07e0, 0x001f }, 0,0
RGB, 2, { 0xf800, 0x07e0, 0x001f }, 1,0
RGB, 3, { 0xff0000,0x00ff00,0x0000ff }, 1,0
RGB, 4, { 0xff0000,0x00ff00,0x0000ff }, 0,0
RGB, 4, { 0xff0000,0x00ff00,0x0000ff }, 0,1
RGB, 4, { 0xff0000,0x00ff00,0x0000ff }, 1,0
RGB, 4, { 0xff0000,0x00ff00,0x0000ff }, 1,1
The meteor SETGEO oformat method of setting pixel geometry works in
compatibility mode until a SACTPIXFMT is done, so previously written
driver apps don't need reved.
2) FIX FOR ODD-FIELD-ONLY CAP_SINGLEs
Previously, and single CAP_SINGLE ripped as if a CAP_CONTINUOUS had been
issued, not generating a wakeup, and thus eventually falling out of the
tsleep with a EWOULDBLOCK killing the DMA but leaving interrupts on in
the driver and the RISC engine spinning. This underlying cause was that
odd frames were being ignored in the interrupt handler, but cleanup code
for failure clearly needed added too.
To fix this, desired frame fields are counted in bktr_intr, and the
wakeup & client interrupt are issued when WANT_MASK is satisfied. To
support this, RISC interrupts are now generated on both odd and even
frames for single- and double- field captures. 'works very well.
3) CAP_SINGLE cleanup
As with the failed odd-field captures, interrupts and the risc engine
weren't being disabled whenever the tsleep fails (e.g. timeout) when
doing a CAP_SINGLE. I just added the appropriate cleanup code.
I also suppressed the useless logging of the ERESTART (-1) return of
tsleep for the successful case; we got our wakeup so there's no error.
That's about it. Hope you find it useful.
Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970424204858.07591>