Subject: Re: framebuffer access
To: Radek Kujawa <firstname.lastname@example.org>
From: Michael <email@example.com>
Date: 11/13/2005 10:38:08
> > An ioctl to read informations about framebuffer geometry,
> > organization and so on exists, maybe it should be extended. Or
> > another ioctl uses what this one uses with additional fields for
> > offest and size.
> I think this is very good idea. I'm no expert but I think we should
> add another ioctl. Such ioctl should return structure with following
> information (at least) :
> - off_t offset
> - size_t size
> - ? organization - this is very important when accessing fb in
> non-paletted mode, because now in user-space we have no idea how
> things are stored in fb memory
At least geometry and colour depth are returned by
ioctl(WSDISPLAYIO_GINFO), but it doesn't tell you anything about colour
format, there's no way to tell if it's RGB or BGR in 24bit or 32bit mode
and you'd have to probe endianness yourself. Well, I've never seen a PCI
framebuffer that uses anything else than RGB so that may be a safe bet
but ffb and many SBus framebuffers use BGR (not that we support wscons
on a single SBus 24bit framebuffer so far, but this will change) so an
app that assumes RGB would look funny on any of these.
> This should be enough to write cross-platform apps using wsdisplay.
> Extending drivers to support this ioctl should be straightforward, am
> I right?
Adding the ioctl is easy, just a few lines of code in a handful drivers.