Here's a fun sequence of patches. What it does is make fb support bitmaps (depth 1 pixmaps) that are stored in 8 bits per pixel. Why would you want to do this, you ask? Well, Glamor wants to use GL for all rendering, and GL has no support for 1bpp surfaces. Making fb support bitmaps in 8bpp means we'll have "native" format support in GL for the same pixmaps which means we can map them instead of copying them.
The tricky parts here involve stippling and copy plane operations, those are handled by creating a fetching function that reads 32 bytes from the source and converts that into 32 bits. I've run the piglit-wrapped X test suite with these changes and it now matches the old code A new function, fbSetBitmap8bpp, can be called by drivers to select this new mode. I can easily imagine changing that function into something which took the actual bpp instead of only offering a boolean, in case we want to also support 32bpp bitmaps. Just rename these two macros to avoid potential conflicts: [PATCH 1/4] fb: Rename READ/WRITE macros to FB_READ/FB_WRITE Makes sure we don't try to fetch data beyond depth when doing XY GetImage: [PATCH 2/4] fb: Clear invalid plane mask bits in GetImage The fb changes: [PATCH 3/4] fb: Add support for 8-bpp pixmaps And the way I tested this: [PATCH 4/4] ephyr: Add -bitmap8 flag to specify 8 bpp for bitmaps -keith _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
