Subject: Re: wscons & framebuffers
To: Chris G. Demetriou <email@example.com>
From: Brett D. Slager <firstname.lastname@example.org>
Date: 03/22/1999 00:39:39
In message <email@example.com>, you wrote:
> "Brett D. Slager" <firstname.lastname@example.org> 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
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
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.