From owner-freebsd-multimedia  Thu Mar 27 19:13:39 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id TAA15091
          for multimedia-outgoing; Thu, 27 Mar 1997 19:13:39 -0800 (PST)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15085
          for <multimedia@FreeBSD.ORG>; Thu, 27 Mar 1997 19:13:37 -0800 (PST)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id TAA04938; Thu, 27 Mar 1997 19:13:38 -0800 (PST)
Message-Id: <199703280313.TAA04938@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Randall Hopper <rhh@ct.picker.com>
cc: multimedia@FreeBSD.ORG
Subject: Re: Bt848 enhancements for this week 
In-reply-to: Your message of "Thu, 27 Mar 1997 21:49:40 EST."
             <19970327214940.40108@ct.picker.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 27 Mar 1997 19:13:37 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


Okay, I buy the concept. All what we need is someone with the databook
to implement Randall's proposal and is not difficult to implement.

Any takers, cause I am swamp/sweating with work related stuff.


	Tnks!
	Amancio

>From The Desk Of Randall Hopper :
> Amancio Hasty:
>  |For apps which write directly to the vga's linear frame buffer you want
>  |to be able to set the correct pixel order for the card. And for apps
>  |which don't write directly to the frame buffer you can save  byte
>  |swapping in the X server by presenting a matching pixel order to
>  |the X server.
>  |
>  |We need a way to modify IOCTL_GEO_RGB16 and IOCTL_GEO_RGB24 to pass along
>  |the pixel order. Then in build_dma_prog set the appropiate
>  |bits for bktr_color_ctl based upon capturing even, odd  , or even and odd
>  |frame, and the color depth 16 bits vs 32bits.
> 
> What might be a nice interface for this is to have the driver accept 4 GEO
> values:  the pixel depth, and 32-bit masks for R, G, and B:
> 
>           GEO_DEPTH
>           GEO_R_MASK
>           GEO_G_MASK
>           GEO_B_MASK
> 
> This is general and would cover byte swapping as well as being able to
> support other pixel formats supported by the hardware (e.g. 5-6-5 16bpp).
> The driver can fail the "set" ioctl for unsupported formats.  
> 
> From an app perspective, a QUERY_GEO ioctl to get the supported formats
> would be a useful API to have along side.
> 
> Randall