Summarized Changelog for the i810/i815 Framebuffer Driver Changes (0.0.34) o Added DirectColor visual support. This is activated at load/boot time with the "dcolor" ("dcolor=1" if module) option. Can be turned on/off anytime in the console (only) by using "fbset -nonstd 1/0". What is DirectColor anyway? DirectColor uses a colormap for each of the color components (RGBA). In TrueColor, the pixel value of each color component translates directly to color intensity. In DirectColor, the pixel value is an index to the colormap, the contents of which translates to color intensity. If the colormap is filled up linearly, then DirectColor behaves essentially like TrueColor. The true value of DirectColor lies on the fact that the colormap can be adjusted dynamically. XFree86 utilizes DirectColor for gamma adjustment. Try the xgamma utility. If this works for your card, then your card is most probably in DirectColor. DirectColor is a bit complicated to code, thus most fbdev drivers do not support DirectColor. Also, some applications do not recognize this format. One of them is DirectFB. So disable this format when using DirectFB. Changes (0.0.33) o Added a few watermark values for very low and very high resolutions and refresh rates. This might increase picture stability at those settings. o Should now be able to scan for stale memory, and remove them as necessary. This happens when DirectFB did not cleanly exit. o Improved security o Fixed minor memory leaks Recommended upgrade if you use DirectFB a lot, since each crash will really eat a lot of resources. This is especially true if you reboot very seldomly. Otherwise, there's no other major change. Changes (0.0.32) o Optimized console acceleration even more. Expect around a 30% increase. o Relaxed horizontal and vertical resolution limit to 2048x2048. Note, I'm not sure if the hardware is capable of horizontal active lengths greater than 1600, so do your adjustments slowly and in small increments, and prepare to manually turn of your monitor, just in case :) o Added grayscale support. Use 'fbset -grayscale true'. o Added support for FBIO_GETVBLANK ioctl. This particular ioctl will return the current timing status, such as vblank, vsync, counts, etc. This is a standard FB ioctl, but only matroxfb has this enabled. o Changed interrupt handling (vsync notification) in an attempt to prevent some race conditions. The race condition is relatively harmless, which rarely manifests as occasional frame skips. Personally, I haven't encountered them. o Attempt to improve the security of the hardware interface: - The MMIO and the shared area are now read-only. If the client is not root (intentionally or by accident): - potentially insecure instructions and the entire 3D instruction set will be disabled. - blitting coordinates will be verified to ensure that critical regions of video memory, notably command buffers, will not be overwritten. - the length of each instruction will be verified - acceleration will always be done synchronously (slower) For root clients, the entire range of instructions is fully available, and the instructions go directly to the hardware. Presently, only DirectFB uses this interface. If you run DirectFB as a regular user, it will fail with a segmentation fault, _unless_, you update DirectFB with DFB-0.9.13-i810-0.0.5a patch. This allows DirectFB to be executed as nonroot (provided you relaxed the permissions of your system, which _should_ not be done). I attempted to crash the graphics chipset by passing the i810fb driver various invalid instructions, or by overwriting the critical region with various blit commands. The safeguards seem to work. Of course, other holes exist, so disable the interface if you do not need it. Changes (0.0.31) o Improved cursor behavior. The hardware cursor will now approximate the behavior of the cursor of the VGA console. a. Ability to change appearance b. Ability to take the color of the underlying text A good example is emacs. The default behavior of emacs is to change the "underline cursor" to a "block" cursor. You can also change the appearance of the cursor using "escape" commands -- echo -e '\033[?nc' where: n = 0; default cursor (underline) 1; invisible cursor 2; underline cursor 3; 1/3 cursor 4; 1/2 cursor 5; 2/3 cursor 6; block cursor See /usr/src/linux/Documentation/VGA-softcursor.txt for more information. The software cursor, on the other hand, misbehaves the most especially when console acceleration is enabled. It has a fixed color, and sometimes the color is incorrect at different bit depths :(. This is also fixed. o Use of interrupt handling when waiting for vertical refresh. This is pertinent only to DirectFB users. If you notice that DirectFB (video/apps) is shaky, or flickers a lot, you can try to use this. This is similar to the matrox-waitforvsync patch supplied with the DirectFB tarball. However, the interrupt is actually triggered at some time after the start of vertical blanking, not vertical sync. To enable this in DirectFB, you have to add the following line to either /usr/src/linux/include/linux/fb.h or to the DirectFB header files: #define FBIO_WAITFORVSYNC 0x4620 Then recompile DirectFB. To enable this in the driver, add the boot option, "vsyncirq", or the module option "vsyncirq=1". Then run your DirectFB application again. You might get an improvement or none at all (flicker, CPU usage, etc), it depends on a lot of things. Note: the interrupt handler is installed only when the "hardware interface" is used, and uninstalled when freed. This is because the same IRQ is also used by DRM. So if you launch DirectFB applications with the "--dfb:no-hardware" flag, the interrupt handler will not be installed, and DirectFB will revert to the regular CGA/MDA register polling to wait for vertical refresh. WARNING: Because the kernel DRM module also installs an interrupt handler for the same IRQ and for the same device, it will conflict with i810fb's interrupt handler. This will happen when X/DRM is active, then you run a DirectFB application that waits for vertical refresh (df_andi, for instance). You should notice that df_andi will pause for 2 seconds, after which it will continue on. However, interrupt handling is disregarded at this point, and CGA/MDA register polling is done by DirectFB instead. To reenable interrrupt handling, you have to exit X. X/DRM should be unaffected by this IRQ conflict, I think :-). o Improvements to pixelclock calculation (the effects are probably insignificant already) o Fixed pixelclock recognition when Intel timings are used o A few minor fixes Changes (0.0.30) Minor update release. o Fixed graphics pipeline flushing problems. The symptom of this problem is an occasional blank screen that is "unblanked" only when the framebuffer is written to/read from again. This is especially true if hardware panning is enabled. o Fonts with heights and widths that are not a multiple of 8 pixels should display properly now, ie 8x9 fonts. o VESA blanking should work properly now, ie. "setterm -blank