Hi,

sorry for not reporting back.  Testing this was more tricky than I
expected it to be (among others: defective type5 keyboard, defective
13W3->VGA adaptor cable, machine located in a not-always-accessible
colocation, -current being VERY unstable on the replacement U10 I
planned to run the tests on).  Anyway...

On Mon, Oct 11, 2004 at 02:18:35PM +0200, Timo Sch?ler wrote:
> > ... now building X server...
> did it work?

... XFree86 is now working on this U10 here, on the Creator3D.

Here's the recipe what I did to get it working:

 - use a -current kernel.  2.0_RC4 doesn't have all the necessary bits
   (e.g. ioctl WSDISPLAYIO_LINEBYTES).

 - set up the kernel with these options:

# Creator3D
ffb*           at mainbus0
wsdisplay*     at ffb?
# keyboard / mouse
wskbd*          at kbd?                 # console ? 
wsmouse*        at ms?

options         RASTERCONSOLE           # fast rasterop console
options         RASOPS_CLIPPING
options         FONT_GALLANT12x22       # the console font
options         FFBDEBUG
options         WSEMUL_SUN              # sun terminal emulation
options         WSEMUL_VT100            # VT100 / VT220 emulation
options         WS_KERNEL_FG=WSCOL_GREEN
options         WS_KERNEL_BG=WSCOL_BLACK
options         WSDISPLAY_COMPAT_SYSCONS# emulate some ioctls
options         WSDISPLAY_COMPAT_RAWKBD # can get raw scancodes

 - patch the kernel with John Heasley's "creator.diff" patch from
   (http://www.shrubbery.net/~heas/creator.diff), otherwise the X server 
   won't find the keyboard.

 - recompile the kernel, boot

 - setup wscons.conf and enable wscons in /etc/rc.conf, like this:

screen  0       -       vt100
screen  1       -       vt100
screen  2       -       vt100
screen  3       -       vt100
screen  4       -       -

   (all other lines are just comments)

   it will set up screen #0 and #1, but complain about lack of memory
   for screens 2-4.  But whatever.

 - setup /etc/ttys to present a login on wscons and on serial console:

console "/usr/libexec/getty suncons"    vt100   off secure
# console -> ttyh0 (serial) / ttyE0 (video)
ttyE0   "/usr/libexec/getty std.9600"   vt100   on secure
ttyh0   "/usr/libexec/getty std.9600"   vt100   on secure

   (watch out! on Ultra10, the onboard serial port A isn't "ttya" but
   "ttyh0" - man sabtty)

 - run XFree86 - I took the binary + XF86Config that John Heasly has 
   provided (http://www.shrubbery.net/~heas/XFree86), but my compiled-
   it-myself binary should have worked as well.

   Getting "xsrc" to compile with the necessary bits in place was tricky,
   and I'm not sure whether I can easily reproduce it.  You need to do
   it with "xsrc-current" to get the XFree86 "wsfb" driver.

 - I modified John's XF86Config (http://www.shrubbery.net/~heas/XF86Config)
   to only list one screen and one wsfb driver, as I only have one
   Creator3D card (Ultra10 here).

 - XFree86 is working for the wsfb/Creator3D now.  
 
 - The mouse isn't working yet, but this could be a defective mouse
   (have no spare one to test yet).

 - X is *slow*.  I'm running x11perf right now, and comparing its output
   to something I did a while ago on a Pentium-133 with an elderly S3
   card (anno 1998 or so), and the S3 outperforms the Creator by about
   factor 3-20.   I assume that, as of today, the Creator X11 isn't
   accellerated in any way, just having basic "set this pixel"
   functionality.


Warning: NetBSD -current on Sparc64 is quite unstable right now when 
doing largish disk IO (see other thread on port-sparc64).  I was not able 
to do a full "make world" without at least 2-3 hard system crashes.  So 
I run a 2.0_RC4 userland, and for any major compilation things, I also 
boot a 2.0_RC4 kernel.  The -current kernel is used for X11.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert@net.informatik.tu-muenchen.de