Subject: Re: Ultra 5 X11
To: Gert Doering <>
From: Michael <>
List: port-sparc
Date: 02/10/2005 08:14:07
Hash: SHA1


> [ X / -current patches ]
>> this will give you an accelerated wscons console and complete,
>> accelerated X11 (but no hardware-accelerated OpenGL, at least as long
>> as we don't have DRI) on the onboard graphics chip.
> How does "accellerated wscons" work?  I thought wscons just presents
> a dumb frame buffer device to the X server?
We can use the blitter for scrolling, filling rectangles, colour 
expansion and so on. ( machfb uses only the first two - too much work 
and too little gain from the latter ) To attach a wsdisplay device we 
have to provide a rasops_info structure, which contains a bunch of 
function pointers for primitives like copyrows, copycols, eraserows and 
so on - no one says we have to use the generic ones filled in by 
rasops_init(), so machfb replaces them with its own which use the 
blitter - considerably faster ( and less waste of CPU cycles ) than the 
generic ones.

>   Or can XFree86 figure out
> "hey, behind this wscons, it's hiding an Mach64 chip, so let's use the
> XFree86 hardware driver"?
That's exactly what XFree is doing. It scans the PCI bus(es) for 
graphics devices it can use and has its way with them, the only OS 
support it needs is to mmap() PCI resources.

> I definitely lack some understanding how the pieces link together for
> "X on wscons and hardware accelleration".
XFree needs wscons to talk to input devices and to access PCI resources 
of graphics cards, not to do any of the acceleration stuff.

>> The only remaining
>> problem is that the keyboard driver misses the first event.
> Yep, same here (U10, FFB).  But that's really a minor thing.
Yes, but it's annoying, it shouldn't happen and it reminds us of the 
rather patchy nature of current wskbd support in the Sun keyboard 
driver - I only added some missing bits without any real knowledge.

>> Support for FFB cards is on the way but I have no idea about its
>> current state.
> I use wscons on U10/Creator3D with good success.  -current kernel,
> kernel compiled with
>    # Creator3D
>    ffb*           at mainbus0
>    wsdisplay0     at ffb?
>    # keyboard / mouse
>    wskbd*          at kbd?                 # console ?
>    wsmouse*        at ms?
Cool :)

> and it works well.  As far as I understand, it's non-accellerated, 
> though,
> as the XFree86 ffb driver is not used, only the "wscons" driver.
XFree has an ffb driver - did you try to use it? When hacking the cgsix 
driver I found out that XFree's only problems with it were...
- - it wants to access /dev/fb0 but NetBSD has a /dev/fb, a symlink 
resolved it
- - XFree didn't compile the cgsix driver by default.
Maybe getting it to work on FFB is just as easy. ( XFree's cgsix driver 
is unaccelerated as well, but at least it uses the hardware cursor. 
Maybe I'll add some simple blitter operations some day but that's 
pretty low on my priority list )

>> But beware - there are a few nasty problems in the native threads code
>> which occasionally crash the kernel, with X11 running you'd only see 
>> it
>> freeze. Big, threaded apps like Mozilla are pretty likely to trigger 
>> it
>> sooner or later. Light-weight stuff is pretty stable though.
> Is there a way to get "kernel oops" messages to the serial console,
> even if keyboard+monitor are connected to the system?
Probably, there's support for a kernel debugger controlled gdb via some 
serial port, I never used it though.

> I have a PC with a spare serial port available, and it would be useful 
> to actually see
> what happened, instead of just seeing "hmmm, frozen.  bad.  power-cycle
> now."
I think the KGDB stuff is your best bet.

have fun
Version: GnuPG v1.2.4 (Darwin)