Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> writes:

> Hmm, but maybe generic raspos handler requires only "bit per pixel,"
> doesn't it? "The actually significant number of bits" is provided
> by info of each color in other members, I think.

I agree, the total "significant bits" is redundant.

> > > - stride in bytes
> > 
> > Also the offset to the visible area of the frame buffer, and the total
> > height of the framebuffer (non-visible portion included) would be nice to
> > have.
> 
> Sure, but which set of values should we actually have for screen size?
> How about "new" struct wsdisplay_fbinfo like this?

> struct wsdisplay_fbinfo {

> 	u_int stride;	/* horizontal stride in bytes */
> 	u_int voff;	/* offset from the top of VRAM top to start of
> 			   visible area in vertical lines (strides) */

I think voff should be in units of bytes rather than units of
strides (I'm thinking of TGA with stride = width + 4; the video area
probably doesn't start at a multiple of 1028. Besides, the major use
for this field is going to be adding it to a mmap'd pointer, so if it
were in strides, it would always be multiplied by the stride value
anyway.

Otherwise it looks good.

> > - a flag to indicate whether or not colormap changes are accepted? Not
> >   entirely necessary, but nice to have.
> 
> Can't we check it by a return value of WSDISPLAYIO_GETCMAP or
> WSDISPLAYIO_PUTCMAP?

Is WSDISPLAYIO_GETCMAP sufficent for determining the size of the
colormap (the need to size the red, green, and blue arrays before
calling GETCMAP is what I'm noticing here).

        - Nathan