I just upgraded to the 2.2.x kernels (in particular, 2.2.7). I compiled
the kernel with Mach64 frame buffer support.
Here are some relevant card ID things from X:
(--) Mach64: PCI: Mach64 GX rev 1, Aperture @ 0xff000000, Sparse I/O @
0x02ec
(--) Mach64: Clock type: ATI18818-1/ICS2595
(--) Mach64: Ramdac is ATI68860 Rev C
I found that detection in atyfb was failing because the memory aperture
wasn't
enabled. Code that does this can be found in the source for the XFree86
Mach64 server. The URL for that directory is:
ftp://ftp.xfree86.org/pub/XFree86/current/untarred/xc/programs/Xserver/hw/xfree86/accel/mach64/
This happens in the mach64InitAperture function in mach64init.c.
However, in order to do that you need to get the address of an IO port.
This is done in mach64.c. That is done in InitIOAddresses, but parts of
GetATIPCIInformation and the very beginning of mach64Probe are also
needed. I also noticed that X sometimes uses I/O ports instead of
memory-mapped I/O. I wonder if this has any significance?
(I did some of this, but not in a generally-useful way, so I'm not
including a patch.)
Atyfb also hard-codes the DAC and clock chip type for the GX chip, and
those were wrong for me so I changed them. Nevertheless, some colors on
the penguin were wrong and fbset didn't deal with clocks properly.
Also, svgalib programs didn't work, and the screen wasn't restored
properly after XF86_Mach64. Would the latest svgalib and XFree86 fix
this? (No, I don't want a frame buffer X server, because I want all of
the Mach64 acceleration)
-- | Boris Gjenero <bgjenero@undergrad.math.uwaterloo.ca> | | Home page: http://www.undergrad.math.uwaterloo.ca/~bgjenero/ | | "Luke, you're going to find that many of the truths we cling to | | depend greatly on our own point of view." - Obi-Wan Kenobi, ROTJ |- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/