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

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