for kernel.org 2.2.18This page is about understanding and hacking on Apple's control display adapter, as it is included on the motherboard of the 7300, 7500, 7600, 8500 and 8600 PowerMacs.
IMPORTANT! My previous patch to implement mmap() in the 2.4 kernel series was buggy. Hit the link below to get a fixed version!
I'm now running XFree86 4.0 on my Mac, on the control display adapter. See this page for the patches I had to apply.
Currently, I'm trying to find out how one can reliably detect the amount and position of the installed VRAM. There's more info on control here.
Here is a test patch, that adds a piece of code to 2.3 controlfb.c in order to fully detect the VRAM configuration. It will print the results in the kernel log on bootup, like so:
... Starting kswapd v1.6 control: mem at 0x000000: yes, mirrored at: 2M 4M 6M control: mem at 0x200000: yes, mirrored at: control: mem at 0x400000: yes, mirrored at: control: mem at 0x600000: yes, mirrored at: controlfb: Memory bank 1 present, bank 2 absent, total VRAM 2MB Monitor sense value = 0x623, using video mode 18 and color mode 1. fb0: control display adapter ...
If you would like to help, please run the above patch in a 2.3 kernel and report the results back to .
There's also a precompiled kernel here, for your convenience. Note that it may not suit your needs re. compiled-in device drivers and network protocols (PPP is not in).
Update: I've had enough of the detection code that only works on half the machines. This patch (2.3.99 kernels) adds a command-line option to override the detection of VRAM and forces a specific config:
video=controlfb:vram:3 where:
vram:0 | autodetect (default) |
vram:1 | 2MB in bank 1 |
vram:2 | 2MB in bank 2 |
vram:3 | 4MB |
The same is possible if you compile controlfb as a module with this option to insmod:
insmod controlfb vram=3
With standard kernels, XFree is much slower on the control hardware
than Xpmac. This is especially true for all operations that read information
from the screen memory, like scrolling atc. It turns out the problem lies in
the way the VRAM is cached (or not...), in the generic framebuffer code's
mmap() implementation. The console code is not affected, since
it uses a mapping private to the kernel, that has the right cache settings.
Since XPmac doesn't use the framebuffer interface, but rather maps the framebuffer memory direclty, it is not affected by this problem. But it is slower in general compared to XFree...
Here is the clean solution:
Adding a mmap() function to controlfb that sets up the desired
caching. Patches available:
There were lots of speculation about whether control incorporates any hardware accelaration or not.
Well, it seems quite clear that apart from a hardware cursor, there is no hardware accelaration whatsoever.
But, there are things that can be improved:
doubles instead of ints (in userland
only).