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:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=41002

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
[email protected]

----- Original Message ----- 
From: "David Brownlee" <[email protected]>
To: "Julian Coleman" <[email protected]>
Cc: "NetBSD port-atari mailing list" <[email protected]>
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:
>
>> 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 --
>