Date: Thu, 27 Mar 1997 19:13:37 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randall Hopper <rhh@ct.picker.com> Cc: multimedia@FreeBSD.ORG Subject: Re: Bt848 enhancements for this week Message-ID: <199703280313.TAA04938@rah.star-gate.com> In-Reply-To: Your message of "Thu, 27 Mar 1997 21:49:40 EST." <19970327214940.40108@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703280313.TAA04938>