-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

>> Yes. Various HP framebuffers found in hp300 machines, like the CatsEye
>> - depth 6, bpp 8 ( or more? I'm not too sure... ). Tomcat uses depth 1
>> bpp 8 if I remember correctly.
>
> Umm, in this case, actually topcat could have bpp of 8 but various
> (from 1 to 8?) depth.
Apparently. The register layout is /very/ similar, it's only additional 
bitplanes and blitters.

> Maybe we should provide info about "the number of bits that are
> actually significant" for FBs with bpp of 8 or less, right?
> (I don't know if there are any FBs with bpp of 2 or 4, though)
I think all this can be handled if we don't assume that 8 bit per pixel 
implies a 256 colour palette.

> Current rasops handles these N depth and 8bpp flamebuffers
> by rasops8 and RI_FORCEMONO flag, but rasops2 and rasops4
> are not implemented yet.
Shouldn't be necessary. Making a palette / device colour map for 
catseye isn't at all problematic, it should even work with monochrome 
8bit framebuffers.

> I don't have any particular idea which type of info should be passed
> from kernel to userland by the new WSDISPLAYIO_GINFO ioctl, but
> I'll prepare one reserved member like "uint32_t flags" for now.
>
> How about this one? (maybe some member names should be rethinked 
> though)
> ---
> struct wsdisplay_fbinfo {
> 	/* compat members with old structure */
> 	u_int height;	/* height of visible area in pixels (lines) */
> 	u_int width;	/* width of visible area in pixels */
> 	u_int depth;	/* bits per pixel */
> 	u_int cmsize;	/* color map size (entries) */
>
> 	/* extended members from here */
> 	u_int vramsize;	/* total VRAM size in bytes */
> 	u_int stride;	/* horizontal stride in bytes */
> 	u_int voff;	/* offset from the top of VRAM top to start of
> 			   visible area in bytes */
> 	u_int hoff;	/* offset from each stride to start of
> 			   visible area in horizontal pixels (or bytes) */
> 	off_t mmapoff;	/* offset to be passed to mmap() to map VRAM region */
>
> 	/* depth info for 2/4/8 bits per pexel displays */
> 	u_int bitnum;	/* number of bits actually significant in bpp */
> 	u_int bitpos;	/* which bit starts at */
>
> 	/* depth info for 15/16/24/32 bits per pexel displays */
> 	/* XXX should be u_char like struct raspos_info? */
> 	u_int rbitnum;	/* number of bits for red */
> 	u_int gbitnum;	/* number of bits for green */
> 	u_int bbitnum;	/* number of bits for blue */
> 	u_int rbitpos;	/* which bit red starts at */
> 	u_int gbitpos;	/* which bit green starts at */
> 	u_int bbitpos;	/* which bit blue starts at */
>
> 	uint32_t flags;	/* reserved; will be used to pass fb specific info */
> };
Why don't we just make up a 256-entry device colour map where all 
entries point to valid values for the underlying framebuffer and some 
ioctl to retrieve a pixel value from a colour map? This way we could 
hide most weirdnesses, clients would only be required to deal with 
palettes shorter than 256 entries and it wouldn't matter anymore which 
actual values represent a black or a white pixel in something like 
topcat.
I think it should be possible for the client to get away without having 
to deal with bit-offsets in pixel values directly on 8bit displays, 
even if these do less than 8 bit colour.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQkLarspnzkX8Yg2nAQKyEAf/S25UK7nuDJP5s8XZnrZ2hTXpOXxEE/8G
ajw/16fKgXn4rO5eARpjCs9SqD1a9eP1usb6Kb4K6Ki6+CZpB9ukHixFd58AmxMK
/EHpXeJruam79JT9t6538VjwT3kg/A5lgfywFpZju/SOZ8J+TKqkUZWvBGICsiuy
1vf76TAAGkWvy0LasCiRBJMa02T2CuQoGo/7dgPe2GdhfP2XOTbZ6B4m9TMiHoPB
3D/XVvObdy74+7ZnQv6Jf5+X5TnMJW33upIhQZRSPaXKSydrWPAsQ3I9w4pCifJG
I3A09tC2opmmwBaJMIiSvDYClpABX/wa7asd9dQGtsADlLFfuwsPpw==
=Xvoj
-----END PGP SIGNATURE-----