Date: Thu, 27 Mar 1997 21:49:40 -0500 From: Randall Hopper <rhh@ct.picker.com> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: multimedia@FreeBSD.ORG Subject: Re: Bt848 enhancements for this week Message-ID: <19970327214940.40108@ct.picker.com> In-Reply-To: <199703261902.LAA05311@rah.star-gate.com>; from Amancio Hasty on Wed, Mar 26, 1997 at 11:02:13AM -0800 References: <199703261237.HAA02315@netwolf.NetMasters.com> <199703261902.LAA05311@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970327214940.40108>