linux/Documentation/fb, branch v2.6.34

fbdev: rename imacfb.txt to efifb.txt and change imacfb to efifb.

2010-04-07T15:38:02Z

Rename imacfb.txt to efifb.txt since imacfb was moved to efifb,and change imacfb to efifb. Signed-off-by: Justin P. Mattock Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

viafb: documentation update

2009-12-16T15:20:05Z

We now support the VX855, and the VX800 is no longer unaccellerated. viafb_video_dev was removed as it was useless. Signed-off-by: Harald Welte Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan Cc: Scott Fang Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbdev: Migrate mailing lists to vger

2009-11-30T21:46:04Z

The fbdev mailing lists at SourceForge have been migrated to a single mailing list at kernel.org: linux-fbdev@vger.kernel.org. Signed-off-by: Geert Uytterhoeven Acked-by: Jean Delvare Signed-off-by: Linus Torvalds

matroxfb: make CONFIG_FB_MATROX_MULTIHEAD=y mandatory

2009-09-23T14:39:56Z

I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just always enable it. There are many reasons for doing this: * CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it definitely works or we would know by now. * Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set results in the following build warning: drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open': drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true' drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release': drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true' This is nothing to be worried about, the driver will work fine, but build warnings are still annoying. * The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD, which is described in the config help text, no longer works: you can't load the same kernel module more than once. * I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code significantly slower, contrary to what the help text says. A few extra parameters on the stack here and there can't really slow things down in comaprison to the rest of the code, and register access. * The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%. * One less configuration option makes things simpler. We add options all the time, being able to remove one for once is nice. It improves testing coverage. And I don't think the Matrox adapters are still popular enough to warrant overdetailed configuration settings. * We should be able to unobfuscate the driver code quite a bit after this change (patches follow.) Signed-off-by: Jean Delvare Acked-by: Petr Vandrovec Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ep93xx video driver

2009-09-23T14:39:51Z

EP93xx video driver plus documentation. Signed-off-by: Ryan Mallon Acked-by: H Hartley Sweeten Cc: Daniele Venzano Cc: Russell King Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Documentation/fb/vesafb.txt: fix typo

2009-06-17T02:47:58Z

Signed-off-by: Paul Menzel Cc: Gerd Knorr Cc: Nico Schmoigl Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

trivial: Miscellaneous documentation typo fixes

2009-06-12T16:01:47Z

Fix various typos in documentation txts. Signed-off-by: Matt LaPlante Signed-off-by: Jiri Kosina

uvesafb: documentation update

2009-04-07T15:31:09Z

Update the uvesafb documentation to accurately reflect the default options used by the driver. Signed-off-by: Michal Januszewski Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbdev: remove cyblafb driver

2009-04-01T15:59:33Z

A tridentfb driver has all the functionality of the cyblafb driver without the bugs of the latter. Changes to the tridentfb driver: - FBINFO_READS_FAST added to the tridentfb. The cyblafb used a blitter for scrolling which is faster than color expansion on Cyberblade chipsets. The blitter is slower on a discrete Blade3D core. Use the blitter for scrolling in the tridentfb only for integrated Blade3D cores. Now, scrolling speed is about equal for the tridentfb and the cyblafb. - a copyright notice addition is done on request of Jani Monoses (the first author of the tridentfb). Tested on AGP Blade3D card and PCChips M787CLR motherboard: VIA C3 cpu + VT8601 north bridge (aka Cyberblade/i1). Signed-off-by: Krzysztof Helt Cc: "Jani Monoses" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices

2008-12-29T10:00:04Z

PXA27x and later processors support overlay1 and overlay2 on-top of the base framebuffer (although under-neath the base is also possible). They support palette and no-palette RGB formats, as well as YUV formats (only available on overlay2). These overlays have dedicated DMA channels and behave in a similar way as a framebuffer. This heavily simplified and re-structured work is based on the original pxafb_overlay.c (which is pending for mainline merge for a long time). The major problems with this pxafb_overlay.c are (if you are interested in the history): 1. heavily redundant (the control logics for overlay1 and overlay2 are actually identical except for some small operations, which are now abstracted into a 'pxafb_layer_ops' structure) 2. a lot of useless and un-tested code (two workarounds which are now fixed on mature silicons) 3. cursorfb is actually useless, hardware cursor should not be used this way, and the code was actually un-tested for a long time. The code in this patch should be self-explanatory, I tried to add minimum comments. As said, this is basically simplified, there are several things still on the pending list: 1. palette mode is un-supported and un-tested (although re-using the palette code of the base framebuffer is actually very easy now with previous clean-up patches) 2. fb_pan_display for overlay(s) is un-supported 3. the base framebuffer can actually be abstracted by 'pxafb_layer' as well, which will help further re-use of the code and keep a better and consistent structure. (This is the reason I named it 'pxafb_layer' instead of 'pxafb_overlay' or something alike) See Documentation/fb/pxafb.txt for additional usage information. Signed-off-by: Eric Miao Cc: Rodolfo Giometti Signed-off-by: Eric Miao