Banging on Apple's control display adapter

This 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:0autodetect (default)
vram:12MB in bank 1
vram:22MB in bank 2

The same is possible if you compile controlfb as a module with this option to insmod:

insmod controlfb vram=3

Performance problems

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:

Ideas for improvements

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:

Last modified: 20000824