xfree-4.2.1-r2

Ferris · Posted: Tue Jan 21, 2003 2:04 pm Post subject: xfree-4.2.1-r2

I'll ask this here; if it's the wrong place, please redirect me. System
involved is an Ultra2, Creator3D, sun5 keyboard, GDM-20E20 monitor.

1. On this system, xfree-4.2.1 seems to run fine.

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.

Any clues?

Ferris · Posted: Fri Jan 24, 2003 2:00 pm Post subject:

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.

quarantedeux · n00b Joined: 13 Feb 2003 Posts: 29

Hi,

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?

Thanks in advance
Stefan

Ferris · Posted: Thu Feb 13, 2003 2:40 pm Post subject:

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.

3. Otherwise, what error do you see?

quarantedeux · n00b Joined: 13 Feb 2003 Posts: 29

Hi,

Thanks for the reply, I am getting exactly the error message you have mentioned:

==========
Fatal server error:
AddScreen/ScreenInit failed for driver 0
===========

I don't really know which version of Creator3D, is there any command to find this out? In the log file of XFree it says:

=======
(--) SBUS: SUn Elite3D
=======

I will have a look at the bug report you have mentioned, and try to fix this. I am already using the example from Cefwyn, but I think I have to first apply the patch and then try it again.

Thanks again for the quick response, I will keep you informed if the patch solved the problem or not!

best regards
Stefan

quarantedeux · n00b Joined: 13 Feb 2003 Posts: 29

Hi,

I have downloaded the patch for the sunffb driver. But I don't know how and where to apply it. Could you give me a pointer?

Thanks in advance
Stefan

Ferris · Posted: Thu Feb 13, 2003 3:40 pm Post subject:

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

Good luck, and please post how this works, one way or the other.

quarantedeux · n00b Joined: 13 Feb 2003 Posts: 29

Hi,

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!!!

BTW: Great work you Gentoo SPARC Developers! Keep up the good work!

Stefan

Ferris · Posted: Fri Feb 14, 2003 12:45 pm Post subject:

That's great!
If you get a chance, it might be useful for you to add a comment to
bug #15449 to the effect it had caught you.

Regards,

quarantedeux · n00b Joined: 13 Feb 2003 Posts: 29

Hi,

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:

http://www.cr.postgresql.org/Unix/Linux/Splack/splack-current/source/u/afbinit/

Unpack the source and compile it:

Cefwyn · n00b Joined: 27 Nov 2002 Posts: 13 Location: Oslo, Norway

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).

regards,
Cefwyn

quarantedeux · n00b Joined: 13 Feb 2003 Posts: 29

Hi,

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 ...

Stefan

Ferris · Posted: Mon Feb 24, 2003 8:25 pm Post subject:

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.)

Some else is sure to have better information than I do, though.

Cefwyn · n00b Joined: 27 Nov 2002 Posts: 13 Location: Oslo, Norway

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

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.....

Ferris · Posted: Thu Feb 27, 2003 3:32 pm Post subject:

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.
*/

Now, the messages in the Log file are the ones (that for me) look like this:
========================
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
[0] -1 0x00000000 - 0xffffffff (0xffffffff) MX[B]
[1] -1 0x00000000 - 0x00000000 (0x0) MX[B]
[2] -1 0x00000000 - 0x00ffffff (0xffffff) IX[B]
[3] -1 0x00000000 - 0x00000000 (0x0) IX[B]
(II) /dev/fb0: Detected FFB2+/horizontal, Z-buffer, Double-buffered.
(II) /dev/fb0:
(II) /dev/fb0: Detected Creator/Creator3D
==========================
(which on my system, luckily, are still correct).

For a Creator3D, you were seeing FFB, FFB2, or FFB2+ and then
"Detetected Creator/Creator3D"

If instead you are seeing something like
======
(II) /dev/fb0: AFB: Detected Elite3D...
(II) /dev/fb0: BT498 (PAC2) ramdac detected
(II) /dev/fb0: Detected Elite.. AFB firmware not loaded... Forcing no acceleration...
======

then the driver is now misreading your card.

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.

Please let me know how it goes...

Cefwyn · n00b Joined: 27 Nov 2002 Posts: 13 Location: Oslo, Norway

Hi Ferris,

After trying several power offs it finally seems to have cleared things up. Strange thing is that it didn't work at first.. hmmm.. oh well, works now.

thanks :-)

-Cefwyn-

bent · Posted: Thu Mar 27, 2003 11:33 am Post subject:

Anyone got this going a Sparc 20 SX (cgfourteen) yet?

I get this error with both 8 and 24 bits set, and I get this:

...
(EE) SUNCG14(0): Given depth (

is not supported by this driver
(II) UnloadModule: "suncg14"
(EE) Screen(s) found, but none have a usable configuration.
...

Haven't tried changing monitor to the cgsix I never use, if I can't get
it going soon I might try that. By the way X 3.3.6 does work with the
current configuration of cg14 in 24 bits on mandrake.