[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Quik and framebuffer problems on StarMax

OK, I'm back for more help...

Thanks to the help I got from the list, I've got my StarMax running
nicely with a 2.4.20 kernel -- provided I only log in over the network
and provided I don't attempt to mess with the framebuffers.

I'm working with a StarMax 5000/300 Twin Turbo, running Sarge.  It's
got OpenFirmware 2.0.2.

This box has two graphics adapters, a builtin ATI Mach 64 GT (4 MB) and
an IMS TwinTurbo 128 (8 MB) on a PCI card.  If Quik loads the kernel
with `video=ofonly' the ATI card is active with the offb driver as
/dev/fb0.  The (inactive) TT128 shows up as /dev/fb1.  The main problem
here is that the display is heavily distorted by waviness.  The
framebuffer is at 1024x768, and console text is almost totally
unreadable.  The amount of distortion varies with the content of the
screen, however, so (for example) the Debian xdm login shows a very
clear and undistorted Debian logo on the login box, but the text in the
xconsole is completely illegible.  In X, the distortion tracks the
movement of windows about the display.

If I boot without any video= argument, _sometimes_ it will boot cleanly
with the atyfb driver running the ATI card and the imsttfb running the
TT128.  If I explicitly use video=atyfb, however, I get a kernel oops as
soon as it loads the atyfb driver.  I've tried different (and no)
vmode,cmode settings and it still oopses.

If I change the output-device and boot with video=imsttfb and move my
monitor over to the TT128 card, I get a successful boot, but in console
mode every character is followed by a space, with the right half of the
output running off the screen.  On one occasion (I'm not sure what was
different) instead of spaces, I got a solid white square, vertically
offset by one-half line, separating each character.  I have not
successfully configured X on the TT128 at all.

The most frustrating thing here is that two boots with the same options
can produce different results -- it seems to `remember' previous
configurations somehow...  I also cannot find documentation that
explains the interaction between the NVRAM variables and the Quik
parameters; they cover the same things, like which kernel to boot and
what device to find it on, so which has precedence?  I can't find a
pattern to it, except that the NVRAM variable seems to override the Quik
default, but an explicitly typed Quik boot command seems to override the
NVRAM one...

Anyway, any help or even just pointers to documentation on this would be
much appreciated.  The docs I've found are very, very thin on explaining
the Mac framebuffer stuff... and I'm not proficient at reading kernel
module source.

Pax vobiscum; pax cum omnibus.

Thanasis Kinias
tkinias at asu.edu
Doctoral Student, Department of History
Arizona State University
Tempe, Arizona, U.S.A.

Reply to: