On Wed, 4 Feb 2009, Julian Coleman wrote:
Hi,
So, really all NetBSD ports should be building a wsfb
driver, even when accelerated drivers are available for
all supported hardware it can be a useful fallback for
testing...
I think so, yes. That should work for any framebuffer where we can
determine the resolution/depth settings and map the graphics memory. You
also need a catch-all driver that will attach as wsfb if none of the
others
do that. The sparc and sparc64 ports do this, for example.
That makes sense...
For atari, we need to add code to rasops to handle the interleaved
bitplanes
that are used for some of the resolutions. Then, generic wscons support
and,
finally, support in the graphics drivers - can be very easy in the case
of
non-accelerated text mode - any accleration can be added later. Note
that
the grf* code handles this already, so that should make adding code to
rasops
and wscons easier.
Maybe a good first pass would be to force 1bpp mode, in which
case we don't need tp worry about the interleaved bitplanes
and can just treat it like any other monochrome framebuffer.
Currently that appears to involve building in the XFree86
servers, including netbsdPci.c, to get modules/drivers/wsfb_drv.so?
I think we should follow the sparc/sparc64 way here and make X use
/dev/fbn
(fb0 by default). The PCI probe routines are unused in that case.
OK, so that would involve generalising sys/dev/sun/fb* ?
Is that the way forward for other prts, or are we back to building
port specific servers which happen to support wscons?
The advantage of the port-specific servers is that you can add support
for
framebuffers that are not supported by X (Xorg). I have an ET4000-based
adapter in my TT, for which there is no support, so the code would have
to
be ported from XFree 3. The way we should go is to an Xorg server, with
modules supporting the various cards. Note, that I'm not sure if we'd
also
need to add support interleaved bitplanes in the wsfb module (as well as
to
rasops).
Maybe port specific servers could be handled by having loadable
modules similar to Xfree - they could key off the fbX's fb_type.
Probing could be handled by offering the FBTYPE_ to all available
modules until one pick it, falling back to the generic wsfb.
Anyway, I think a generic Xwsfb is probably the best place to
start...
Other ports, e.g. alpha and mips TGA FB's, where there is no Xorg support
are in the same situation.
PS. There is a good description of how the interleaved bitplanes are set
up at:
http://alive.atari.org/alive8/c2p.php
Excellent. Assuming we start with the 1bpp version, should we
take this to tech-x11 to see if any other ports are interested
in the generic /dev/fbX Xwsfb?
--
David/absolute -- www.NetBSD.org: No hype required --