Port-atari archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD/atari Xserver (Was: pushing netbsd-5)

On Wed, 4 Feb 2009, Julian Coleman wrote:


        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

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

        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

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:

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

Home | Main Index | Thread Index | Old Index