Hi,
On Sun, 13 Nov 2005, Michael wrote:
> I'm not sure we should support multiple views in wscons, we can do it
> using the Sun fb devices.
But... aren't fb devices replaced by wscons now? You can't use wscons and
Sun-style fb at the same time? I always thought that fb devices are
sparc specific.

> I think this should be a flag field, like one flag for endianness
> conversion, a couple bits for colour format and so on.
This indeed sounds more logical than using #defines.

> And I'd prefer something like this:
>
> struct wsdisplay_view {
> 	size_t   size;
> 	offset_t offset;
> 	uint32_t width, height;
> 	uint32_t stride, depth;
> 	uint32_t flags; /* colour format, conversion etc. */
> }
We're talking about different views of the same framebuffer memory, right?
Then, do we need width and height information here? These are available
through WSDISPLAYIO_GINFO.

> and then
> struct wsdisplay_view_info {
> 	struct wsdisplay_view *views;
> 	uint32_t count;
> }
>
> so we can just return the number of views when the pointer is NULL -
> after all the userland program has to provide the memory for the view
> table and just guessing it is ugly.
Right, this way is certainly better.

> Most PCI boards will only support 2
> views, but others, like the ffb, could do many more which don't
> necessarily use the same depth or organization.
This sounds very useful. I remember reading about ffb some time ago, it
has completly different memory organization than PCI cards. Just out of
curiosity, is it possible to display 24-bit and 8-bit images at the same
time using ffb memory views?

> Or think video overlays
> - these could be exposed as different views but geometry and colour
> depth/format may be something completely different ( like YUV ).
> Hmm, supporting video overlays here is probably overkill.
Idea is amusing but, someone writing video app would probably do it in X
anyway, xv is supported by many drivers. I don't think there is need for
video interface in wscons ;).

Radek