Here is the clean solution:
Adding a mmap() function to controlfb that sets up the desired
caching. Patches available:I'm now running XFree86 4.0 on my Mac, on the control display adapter. I had a few problems to get it running smooth, but it (mostly) works now.
Since XFree 4.0 has no specific driver for the control adaptor, you have to use the generic framebuffer driver in XFree. However, there are two glitches in the way this driver operates in the current (4.0) XFree release and on the current kernels.
This is probably the first hurdle for newcomers; but it can be tricky for the more experimented as well. Anyway, here is my XF86Config. I've not seen any speed advantage in using shadowfb; therefore it's disabled.
The first problem is a bug in XFree's framebuffer hardware access code. If your framebuffer doesn't start at address 0 inside the VRAM, XFree doesn't get this offset right. On control, which has such an offset, the result is that the display is moved to the left and wraps around the edge to the right side of the screen.
The solution is a patch to fbdevhw.c in the XFree sources. (patch courtesy of Ryuichi Oikawa and Geert Uytterhoeven). It was argued that this patch is not perfect, but it does work for me. I can wait now until a better patch apears in the Xfree releases...
I've also put up a precompiled binary of libfbdev.a, so you can just copy this part into your XFree install. It goes into /usr/X11R6/lib/modules/linux.
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. Here is the
patch that changes the cache attributes on
the framebuffer from (_PAGE_NO_CACHE|_PAGE_GUARDED) to
(_PAGE_WRITETHRU). This speeds up some scrolling operations
by a factor of 4!
My solution here is a temporary solution; I should really implement a specific mmap() funtion in controlfb to apply the right caching. I'll see...
Here is the clean solution:
Adding a mmap() function to controlfb that sets up the desired
caching. Patches available:
The mmap() code is integrated in Paul Mackerras' kernels
starting at 2.4.0-test9.
I've still got an unresolved problem with the keboard map. I'm using a swiss-french keyboard layout, with some characters on <alt>key and <shift><alt>key. I'm modifying the keyboard map with xmodmap; however, some of the keays (notably thos with <alt>) don't work right. The strange thing is that xev shows them absolutely right; but apps eg. xterm still display them wrong... In fact, something adds 0x80 to the keysym before it gets delivered to xterm, which makes '#' (keysym 0x23) appear as '£' (keysym 0xa3). If you know how to solve this, let me know!