From owner-freebsd-multimedia Fri Apr 25 09:03:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24076 for multimedia-outgoing; Fri, 25 Apr 1997 09:03:05 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24071 for ; Fri, 25 Apr 1997 09:03:03 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 25 Apr 1997 12:01:56 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA04377; Fri, 25 Apr 97 12:01:54 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id MAA06595; Fri, 25 Apr 1997 12:01:34 -0400 Message-Id: <19970425120134.00918@ct.picker.com> Date: Fri, 25 Apr 1997 12:01:34 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: Re: The "BT848 RISC Challenge" References: <19970424211546.22989@ct.picker.com> <199704250205.TAA05767@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199704250205.TAA05767@rah.star-gate.com>; from Amancio Hasty on Thu, Apr 24, 1997 at 07:05:46PM -0700 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 |> | | |