2. As initially distributed, 4.2.1-r2, as reported elsewhere, the <l,> keys
were mangled, but <glsgears> ran fine if you could manage to start
it (no l-key).

3. This problem (with key mappings) is now corrected, as suggested in the
comments to bug reports #13073 and especially #14126;

4. However, for me, with this version of <4.2.1-r2>, <glxgears> fails: It
runs and correctly reports its performance, but it does not show
spinning gears; it shows a black window with some interference
patterns off to the side (flashing white lines). 4.2.1 is still fine.

I'll reply to myself, because <the_deuce@yahoo.com (Jason Andryuk)>
provided an answer for glxgears problem in a comment to bug #14126.

My /etc/make.conf was using
CFLAGS=-O2 -pipe -mcpu=v9 -mtune=v9
which should be correct for my system (Ultra2). However, it seems that in
some cases the '-mcpu=v9' is a *bad idea,* while '=v8' works (as is the case
here). Making that change gets glxgears spinning again.

I am told there is a discussion of this somewhere, but I have yet to find it.

I have Gentoo Linux installed on a Sun Ultra60 with a Creator 3D card. I have an SUN Monitor, i think it is a GDM-20E20.
I have problems with configuring XFree86. Has anybody got a working XF86config, which he can post here?

1. Look at, say, Cefwyn's example at
<https://forums.gentoo.org/viewtopic.php?t=24773>
for a working sketeton. It should take very little by way of
configuration to get the Creator/GDM-20E20 combination going.

2. What kind of Creator3D? We have just had a long exchange on this
immediately before you tried your system, so you probably missed it.
There is a bug in the Creator/Elite driver for xfree86
which will cause XF86 startup to fail with a log message:
===========
Fatal server error:
AddScreen/ScreenInit failed for driver 0
===========
If that is what you are seeing, there is a discussion and patch to fix
the xfree Creator/Elite driver at Bug #15449.

OK, here goes.
1. Check in /var/tmp/portage/xfree-4.2.1-r2/ (or whichever version
of xfree you are using.) If you have directories work/xc/.. there,
skip the next step (do step 3 directly)
2. No, no compiled version. In /usr/portage/x11-base/xfree, enter
the command
ebuild xfree-4.2.1-r2.ebuild fetch unpack compile
3. Change into this directory:
/var/tmp/portage/xfree-4.2.1-r2/work/xc/programs/Xserver/hw/xfree86/drivers/sunffb

This is where the patch goes, applied to ffb_driver.c, by, say
patch -b --suffix=.orig < ffb_driver.patch

4. Now, since everything is compiled and installed, all you need to do
is rebuild the driver, just by
make
in this directory. You now have a new 'sunffb_drv.o'; it needs to
go into /usr/X11R6/lib/modules/drivers

Great it worked! I have applied the patch from bug report #15449. I am using the XF86Config from <https://forums.gentoo.org/viewtopic.php?t=24773> . Now X comes up nicely! Thank you very much for your help!!!

I just wanted to give a small update about the sunffb driver. If you use this driver without acceleration X is very slow and it is not nice to work with. To make the acceleration work you have to load the microcode for the SUN Elite 3D card. The file is called afb.ucode and you can get it from a Solaris box. It is under /usr/lib. Copy this file to /usr/lib on your Gentoo Linux machine and download afbinit to load the microcode. afbinit can be found here:

Copy the file afbinit to lets say /usr/sbin. The command to load the microcode is:

Code:

/usr/sbin/afbinit /dev/fb0 /usr/lib/afb.ucode

You have to make sure to load the microcode before you start the X server. You can put the above command into /etc/conf.d/local.start.
After loading the microcode and starting X you will recognize an extreme improvement!

Do you know if the afb.ucode works with Creator3D cards too? I tried it on my Ultra 10 but no matter what I did, whenever I ran the afbinit, my monitor would just go blank and then tell me there was no signal (while still on the console).

The afb.ucode should also work with Creator3D cards.
Does the kernel you are using have framebuffer support for that specific device? If not recompile the kernel with framebuffer support for Creator3D cards. Then try it again, it should work ...

Actually, I'd tend to believe David Miller's "rc.afb" file: If boot time doesn't
find an Elite card, don't load this microcode. As an experiment, I tried
it with a Creator3D card (ffb2+). I had the same results as Cefwyn, and
it took a power cycle to get the Creator back. (Otherwise, after a reset,
it was identified as a "sort of" Elite3D which nothing really knew what to
do with.)

Thanks. I guess since you have the same problem Ferris it's not me messing it up

I'm trying to find some way to get X to run better. After I tried the afb.ucode thing (now removed and rebooted a couple of times since then), X is very sluggish compared to what it was before. Especially the redraw of windows (like web pages in mozilla) is horribly slow compared to before when it was quite zippy...

Are you experiencing anything similair Ferris?

-Cefwyn-

Edit:
found the problem; X now thinks I have a elite3d card. Now to get it to understand I have a creator3d.....

Let's see if this gets us anywhere. These are rambling thoughts, so
please bear with me.

(Note that by 'power off' I meant really off, not standby. )

First, what the afbinit program tries to do is load Elite microcode into a
set of registers which the Creator does not have (Elite does more graphics
processing onboard, otherwise it is the same as a Creator. Hence, the
shared driver.) Trying to load this code into a Creator card is a bad idea,
as we have taught ourselves. Thus, the comment in the source:
/* Note, if you try to enable a non-existant float chip
* this will lock up the chip.
*/

The only thing I can think of off the top of my head if physically unplugging
the system to cycle power doesn't clear this up is to hardwire the
board selection into ffb_driver.c This is easy to do, but not guaranteed
to fix your problem.

1. If you see the AFB: Detected Elite.. (II) line,
it comes from FFBProbeBoardType at ffb_driver.c, line 485 or so.
Easiest way to disable this is to change the line
val &= 0x7f;
to
val = 0;
and hope the strapping bits are going to be read correctly.

2. If you are seeing the second (II) /dev/fb0: Detected Elite
line, you are in FFBScreenInit at about ffb_driver.c, line 775, and
the "nonsense" reported by Creator when you try to read the
nonexistent FEM register nas changed. Since you don't have an Elite,
changing
afb_fem = *(unsigned int *) ((char *) pFfb->regs + 0x1540);
to
afb_fem = 0;
will get you past this problem.
In fact, you should see neither or both of these misidentifications, since they come from the same kind of test.

3. If instead those tests are coming out OK for you, but you seeing the
(--) SBUS:(0xf0066a58) Sun Elite3D at /SUNW,ffb@1e,0
nonsense neat the beginning of the Xlog file, you are seeing a problem
recently introduced into XF86 which shows up in the Sbus code in
xc/programs/Xserver/hw/xfree86/common/xf86sbusBus.c code, or
perhaps from an incompatibility introduced into
xc/programs/Xserver/hw/xfree86/os-support/bus/Sbus.c
(It seems to be an "off by 1" indexing problem)

Unfortunately, I can see where the message comes from, but I have
no idea why or when the problem arose. It has not mattered to me, so
I haven't pursued it (it doesn't seem to matter, so long as the driver
sorts things out correctly?). There is a discussion of this someplace else
in the forum, I believe, but I don't have a reference off hand.

Maybe this will give you some ideas or trigger something from someone
else.