Subject: Re: framebuffer access
To: Radek Kujawa <streamer@cytrynka.infoland.int.pl>
From: Michael <macallan18@earthlink.net>
List: port-sparc64
Date: 11/13/2005 17:53:43
Hello,

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

Not really. Both have their benefits and shortcomings.

> You can't use wscons and Sun-style fb at the same time?

You can. Wscons is more about terminal emulation - there's on way to
access a framebuffer without a (virtual) console defined on it, you get
lots of weird problems with more than one wsdisplay.

> I always thought that fb devices are sparc specific.

Yes and no - they're used only on sparc(64) but the code itself is in no
way hardware 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?

Yes.

> Then, do we need width and height information here?

Depends - the different views don't necessarily agree about colour
depth. Of course the question remains if we need to support something
like this.
Besides that it's just convenience, to have all informations one needs
in one place.

> Just out of curiosity, is it possible to display 24-bit and 8-bit
> images at the same time using ffb memory views?

Yes. And not all 8bit views need to use the same palette ( if I
remember correctly you can have 32 or 64 different ones ). There's a
special plane which controls how any given pixel is displayed.

> > 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 ;).

True. It just crossed my mind as an example ;)

have fun
Michael