Subject: Re: Ultra 5 X11
To: Gert Doering <email@example.com>
From: Michael <firstname.lastname@example.org>
Date: 02/10/2005 08:14:07
-----BEGIN PGP SIGNED MESSAGE-----
> [ 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
> 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?
> and it works well. As far as I understand, it's non-accellerated,
> 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
- - 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
>> freeze. Big, threaded apps like Mozilla are pretty likely to trigger
>> 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
I think the KGDB stuff is your best bet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----