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)

David recently helped me get X up and running on my TT030. I have a full NetBSD 5.0 install (including X packages) on my TT and onto that I dropped XF68_FBDev from NetBSD 1.6.1. I didn't have libz.so.0 but I just symlinked that from libz.so.1.0 and it seemed to work. The server was able to boot up at 640x400 with 1 bit color depth after I installed XF86Config.FBDev_sample from ftp://ftp.netbsd.org/pub/NetBSD-archive/NetBSD-1.4.2/atari/misc/.

David patched my ST_POOL_SIZE and after that I was able to get 640x480 with 4 bit color depth:

ataritt# gdb --write /netbsd
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "m68k--netbsdelf"...(no debugging symbols found)

(gdb) print st_pool_size / 8192
$2 = 24
(gdb) set st_pool_size = 48 * 8192
(gdb) quit

I don't have an Atari monitor so I couldn't try the special TT-high mode.
A PR has been filed to either remove the need for ST_POOL_SIZE or default to sizing it automatically:

I haven't really done any thorough testing but I do see at least the server starts up and I get a few xterms and a clock.

David Ross

----- Original Message ----- From: "David Brownlee" <abs%NetBSD.org@localhost>
To: "Julian Coleman" <jdc%coris.org.uk@localhost>
Cc: "NetBSD port-atari mailing list" <port-atari%netbsd.org@localhost>
Sent: Friday, February 06, 2009 5:41 PM
Subject: 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