Date: Fri, 25 Apr 1997 12:01:34 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: multimedia@freebsd.org Subject: Re: The "BT848 RISC Challenge" Message-ID: <19970425120134.00918@ct.picker.com> In-Reply-To: <199704250205.TAA05767@rah.star-gate.com>; from Amancio Hasty on Thu, Apr 24, 1997 at 07:05:46PM -0700 References: <19970424211546.22989@ct.picker.com> <199704250205.TAA05767@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't think you read my entire message. Flipping the chip into RGB24 is
done (see the driver I posted yesterday).
The issue is, without bt byte/short swapping enabled, the FIFO data is
rasterized as:
<---- lower addr higher addr ---->
BGRBGRBG ...
Some folks' X servers config their video card for packed 24bpp in the
reverse memory organization:
<---- lower addr higher addr ---->
RGBRGBRGB ...
Byte and word swapping doesn't help you here as the pixel FIFO is 32bits
wide.
It doesn't look like the chip supports writing in this format without a
pixel-hacking RISC program or hue tricks. The basis of my question was, am
I missing something?
Randall
Amancio Hasty:
|Hi,
|
|First of, the Bt848 driver operates in RGB mode and has been that way since
|the beginning. What is currently out in beta in
|ftp://rah.star-gate.com/pub/bt848-clip.tar.gz is the swapping of pixel
|orders and clip list support.
|
|The Bt848 supports RGB32, RGB24, RGB16, and RGB15.
|
|The supported modes are RGB32 (METEOR_GEO_RGB24) and RGB15 ( METEOR_GEO_RGB16)
|needless to say that the METEOR_GEO_RGBXXX are misnomers.
|
|the following table hopefully will make all this clear, from the
|Bt848 databook:
|
|FIFO Input Output of Fifo
|31:24 [31:24] [23:16] [15:8] [7:0]
|23:16 [23:16] [31:24] [7:0] [15:8]
|15:8 [15:8] [7:0] [31:24] [23:16]
|7:0 [7:0] [15:8] [23:16] [31:24]
|
|If RGB24 is desired, then we can add an ioctl to tell the driver
|to dma the video using rgb24.
|
|A few ways of accomplishing this is to:
|
|1. to create a bt848 ioctl call with the appropriate correct color depth.
| bt848SETRGB and pass a value of the color depth desired
|
|2. we can generalized the mechanism for setting the pixel order to also
| determine the color depth.
|
|3. Create a new bt848 ioctl call which has geometry, color depth, pixel
| order and video frame buffer info .
|
|----
|
|
|Briefly, we can do it.
|
| Amancio
|
|
|From The Desk Of Randall Hopper :
|> Thought that'd grab your attention :-)
|>
|>
|> THE CHALLENGE: Figure out how to get the BT848 to DMA pixels in
|> RGBRGB packed 24bpp (3Bpp) format to the frame buffer or
|> memory.
|>
|>
|> It'd be cool if we could do this to support those of us whose Xservers
|> config the card for this format. For now, the driver limits direct video
|> in 24bpp to those folks that have BGRBGR packed 24bpp organization.
|>
|> SOME OPTIONS:
|>
|> 1. Put the chip in RGB32 pixel FIFO mode with byte and short swapping
|> enabled (ARGBARGB). For each pixel, write 2 RISC instructions: a
|> SKIP to skip the Alpha, and a WRITE to blast the RGB.
|>
|> Hmmmmmm, let's see....that's only 2.5 Megs for a 640x480 image. :-)
|>
|> 2. Rotate the HUE 90 deg. (I'm not kidding. It works. It's ugly but
|> it works!)
|>
|> Anybody know a kindler, gentler way to do this on the chip? :-)
|>
|> Randall
|>
|
|
|
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970425120134.00918>