Subject: Re: XF86 wsfb driver and wscons ioctl
To: None <>
From: Izumi Tsutsui <>
List: tech-x11
Date: 03/06/2005 22:40:09
[resuming this topic]

In article <> wrote:

> > - depth in bits
> The X server calls this bits per pixel if I remember correctly, and depth is
> the number of bits that are actually significant. I would be good to have
> the two.

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.

> > - 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 {
	/* 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 vertical lines (strides) */
	u_int hoff;	/* offset from each stride to start of
			   visible area in horizontal pixels */
	off_t mmapoff;	/* offset to be passed to mmap() to map VRAM region */

	/* depth info for 15/16/24/32 bits per pexel displays */
	/* XXX should be u_char like struct raspos_info? */
	u_int rnum;	/* number of bits for red */
	u_int gnum;	/* number of bits for green */
	u_int bnum;	/* number of bits for blue */
	u_int rpos;	/* which bit red starts at */
	u_int bpos;	/* which bit green starts at */
	u_int gpos;	/* which bit blue starts at */

> - a flag to indicate whether the frame buffer is simple and can be handled
>   by mfb/cfb or is something a bit different, like a VGA or PixelStamp?

I think such device specific features could be determined by

> - 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

Izumi Tsutsui