summaryrefslogtreecommitdiffstats
path: root/drivers/video/cfbcopyarea.c
AgeCommit message (Collapse)Author
2008-04-28fb: add support for foreign endiannessAnton Vorontsov
Add support for the framebuffers with non-native endianness. This is done via FBINFO_FOREIGN_ENDIAN flag that will be used by the drivers. Depending on the host endianness this flag will be overwritten by FBINFO_BE_MATH internal flag, or cleared. Tested to work on MPC8360E-RDK (BE) + Fujitsu MINT framebuffer (LE). Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: <Valdis.Kletnieks@vt.edu> Cc: Clemens Koller <clemens.koller@anagramm.de> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-16fbdev: copyarea function taught to fully support swapped pixel order in bytePavel Pisa
This correct case, when source and destination X coordinates difference is n multiple of pixels in byte. This is probably rare case, but this case should supported for completeness. Reorganization of FB_READL and FB_WRITEL calls results in code size decrease for normal build without swapping support and size with support enabled is reasonable too. [adaplas] Add missing fb_rev_pixels_in_long() prototype. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Signed-off-by: Antonino Daplas <adaplas@gmail.com> [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-16fbdev: Support for byte-reversed framebuffer formatsPavel Pisa
Allow generic frame-buffer code to correctly write texts and blit images for 1, 2 and 4 bit per pixel frame-buffer organizations when pixels in bytes are organized to in opposite order than bytes in long type. Overhead should be reasonable. If option is not selected, than compiler should eliminate completely all overhead. The feature is disabled at compile time if CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set. [adaplas] Convert helper functions to macros if feature is not enabled. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08fbdev: consolidate common drawing functions into a header fileAntonino A. Daplas
Consolidate common drawing functions into a single header file. Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2005-12-12[PATCH] fbdev: Fix incorrect unaligned access in little-endian machinesAntonino A. Daplas
The drawing function cfbfillrect does not work correctly when access is not unsigned-long aligned. It manifests as extra lines of pixels that are not complete drawn. Reversing the shift operator solves the problem, so I would presume that this bug would manifest only on little endian machines. The function cfbcopyarea may also have this bug. Aligned access should present no problems. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07[PATCH] fbdev: Remove software clipping from drawing functionsAntonino A. Daplas
Remove software clipping from imageblit, fillrect and copyarea. Clipping is not needed because the console layer assures that reads/writes doest not happen beyond the extents of the framebuffer. And software clipping tends to hide bugs, if they do exist. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!