In message <87lngqce1z.fsf@redmail.redback.com>, you wrote:
> "Brett D. Slager" <bds@snarf.thnet.com> writes:
> > Additional information that may be desired includes:
> > 
> > [ ... ]
> 
> > u_int	coresize;	/* fb core mmap size */
> > u_int	fboff;		/* fb core memory offset */
> > u_int	fbsize;		/* fb core memory size */
> > u_int	regoff;		/* fb core registers offset */
> > u_int	regsize;	/* fb core registers size */
> 
> These do not belong in this ioctl.  they should be expressed
> indirectly by a bus_space() implementation in user space.  it should
> be possible to map a device's multiple 'spaces' into user space.
> further determining how those spaces correspond to video memory,
> registers, etc., isn't nearly as simple as the "two regions" you
> describe.

No, it isn't that simple.  You've got multiple display buffers, back buffers,
multiple register regions, RAMDACs, and possible aliases of all of them just
to name a few issues.  But simple X support for framebuffers sure would be
easier with the two regions in the ioctl :)  With wscons handling the input,
one Xserver could support a large number of framebuffers in the NetBSD tree
automatically.  I had other designs in mind when I came up with those ioctl
fields, but decided to keep it simple as these fields met the needs at my
hands.

Would the user space bus_space implementation use the device driver d_mmap()
routine for mapped access, or some other mechanism?  What means should be
used for getting the 'space' descriptions out of the kernel?

> > -#define WSDISPLAYIO_GETCMAP	_IOW('W', 66, struct wsdisplay_cmap)
> > +#define WSDISPLAYIO_GETCMAP	_IOR('W', 66, struct wsdisplay_cmap)
> This was not a bug, do not fix it.

Yup.  Oops.  My mistake.  I missed the pointer contents of wsdisplay_cmap.

> cgd

--Brett