Date: Fri, 25 Apr 1997 15:48:24 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randall Hopper <rhh@ct.picker.com> Cc: multimedia@freebsd.org Subject: Re: The "BT848 RISC Challenge" Message-ID: <199704252248.PAA10046@rah.star-gate.com> In-Reply-To: Your message of "Fri, 25 Apr 1997 12:01:34 EDT." <19970425120134.00918@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
First of in PC Land we do refer to BGR to RGB. Not sure if we can support what you want. Heck get an S3 card. Not sure that the a Risc program is the way to do the pixel reordering that is if a risc program can doit at all. The PCI latency will probably kill the risc program. There may be another way of doing this with PCI Byte Enables. Amancio >From The Desk Of Randall Hopper : > 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_RGB 16) > |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 Xserve rs > |> 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 bu t > |> 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?199704252248.PAA10046>