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>