mirror of
https://github.com/raspberrypi/linux.git
synced 2026-01-05 02:37:41 +00:00
eabb032930
The original version duplicated more or less the same algorithms for both system and i/o memory. In this version the drawing algorithms (copy/fill/blit) are separate from the memory access (system and i/o). The two parts are getting combined in the loadable module sources. This also makes it more robust against wrong memory access type or alignment mistakes as there's no direct pointer access or arithmetic in the algorithm sources anymore. Due to liberal use of inlining the compiled result is a single function in all 6 cases, without unnecessary function calls. Unlike earlier the use of macros could be minimized as apparently both gcc and clang is capable now to do the same with inline functions just as well. What wasn't quite the same in the two variants is the support for pixel order reversing. This version is capable to do that for both system and I/O memory, and not only for the latter. As demand for low bits per pixel modes isn't high there's a configuration option to enable this separately for the CFB and SYS modules. The pixel reversing algorithm is different than earlier and was designed so that it can take advantage of bit order reversing instructions on architectures which have them. And even for higher bits per pixel modes like four bpp. One of the shortcomings of the earlier version was the incomplete support for foreign endian framebuffers. Now all three drawing algorithms produce correct output on both endians with native and foreign framebuffers. This is one of the important differences even if otherwise the algorithms don't look too different than before. All three routines work now with aligned native word accesses. As a consequence blitting isn't limited to 32 bits on 64 bit architectures as it was before. The old routines silently assumed that rows are a multiple of the word size. Due to how the new routines function this isn't a requirement any more and access will be done aligned regardless. However if the framebuffer is configured like that then some of the fast paths won't be available. As this code is supposed to be running on all supported architectures it wasn't optimized for a particular one. That doesn't mean I haven't looked at the disassembly. That's where I noticed that it isn't a good idea to use the fallback bitreversing code for example. The low bits per pixel modes should be faster than before as the new routines can blit 4 pixels at a time. On the higher bits per pixel modes I retained the specialized aligned routines so it should be more or less the same, except on 64 bit architectures. There the blitting word size is double now which means 32 BPP isn't done a single pixel a time now. The code was tested on x86, amd64, mips32 and mips64. The latter two in big endian configuration. Originally thought I can get away with the first two, but with such bit twisting code byte ordering is tricky and not really possible to get right without actually verifying it. While writing such routines isn't rocket science a lot of time was spent on making sure that pixel ordering, foreign byte order, various bits per pixels, cpu endianness and word size will give the expected result in all sorts of combinations without making it overly complicated or full with special cases. Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org> Signed-off-by: Helge Deller <deller@gmx.de>
223 lines
5.9 KiB
Plaintext
223 lines
5.9 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
#
|
|
# fbdev core configuration
|
|
#
|
|
|
|
config FB_CORE
|
|
select VIDEO
|
|
tristate
|
|
|
|
config FB_NOTIFY
|
|
bool
|
|
|
|
config FIRMWARE_EDID
|
|
bool "Enable firmware EDID"
|
|
depends on FB
|
|
help
|
|
This enables access to the EDID transferred from the firmware.
|
|
On the i386, this is from the Video BIOS. Enable this if DDC/I2C
|
|
transfers do not work for your driver and if you are using
|
|
nvidiafb, i810fb or savagefb.
|
|
|
|
In general, choosing Y for this option is safe. If you
|
|
experience extremely long delays while booting before you get
|
|
something on your display, try setting this to N. Matrox cards in
|
|
combination with certain motherboards and monitors are known to
|
|
suffer from this problem.
|
|
|
|
config FB_DEVICE
|
|
bool "Provide legacy /dev/fb* device"
|
|
depends on FB_CORE
|
|
default FB
|
|
help
|
|
Say Y here if you want the legacy /dev/fb* device file and
|
|
interfaces within sysfs anc procfs. It is only required if you
|
|
have userspace programs that depend on fbdev for graphics output.
|
|
This does not affect the framebuffer console. If unsure, say N.
|
|
|
|
config FB_DDC
|
|
tristate
|
|
depends on FB
|
|
select I2C_ALGOBIT
|
|
select I2C
|
|
|
|
config FB_CFB_FILLRECT
|
|
tristate
|
|
depends on FB_CORE
|
|
help
|
|
Include the cfb_fillrect function for generic software rectangle
|
|
filling. This is used by drivers that don't provide their own
|
|
(accelerated) version.
|
|
|
|
config FB_CFB_COPYAREA
|
|
tristate
|
|
depends on FB_CORE
|
|
help
|
|
Include the cfb_copyarea function for generic software area copying.
|
|
This is used by drivers that don't provide their own (accelerated)
|
|
version.
|
|
|
|
config FB_CFB_IMAGEBLIT
|
|
tristate
|
|
depends on FB_CORE
|
|
help
|
|
Include the cfb_imageblit function for generic software image
|
|
blitting. This is used by drivers that don't provide their own
|
|
(accelerated) version.
|
|
|
|
config FB_CFB_REV_PIXELS_IN_BYTE
|
|
bool
|
|
depends on FB_CORE
|
|
help
|
|
Allow I/O memory frame-buffer functions to work on displays with 1, 2
|
|
and 4 bits per pixel depths which has opposite order of pixels in
|
|
byte order to bytes in long order.
|
|
|
|
config FB_SYS_FILLRECT
|
|
tristate
|
|
depends on FB_CORE
|
|
help
|
|
Include the sys_fillrect function for generic software rectangle
|
|
filling. This is used by drivers that don't provide their own
|
|
(accelerated) version and the framebuffer is in system RAM.
|
|
|
|
config FB_SYS_COPYAREA
|
|
tristate
|
|
depends on FB_CORE
|
|
help
|
|
Include the sys_copyarea function for generic software area copying.
|
|
This is used by drivers that don't provide their own (accelerated)
|
|
version and the framebuffer is in system RAM.
|
|
|
|
config FB_SYS_IMAGEBLIT
|
|
tristate
|
|
depends on FB_CORE
|
|
help
|
|
Include the sys_imageblit function for generic software image
|
|
blitting. This is used by drivers that don't provide their own
|
|
(accelerated) version and the framebuffer is in system RAM.
|
|
|
|
config FB_SYS_REV_PIXELS_IN_BYTE
|
|
bool
|
|
depends on FB_CORE
|
|
help
|
|
Allow virtual memory frame-buffer functions to work on displays with 1, 2
|
|
and 4 bits per pixel depths which has opposite order of pixels in
|
|
byte order to bytes in long order.
|
|
|
|
config FB_PROVIDE_GET_FB_UNMAPPED_AREA
|
|
bool
|
|
depends on FB
|
|
help
|
|
Allow generic frame-buffer to provide get_fb_unmapped_area
|
|
function to provide shareable character device support on nommu.
|
|
|
|
menuconfig FB_FOREIGN_ENDIAN
|
|
bool "Framebuffer foreign endianness support"
|
|
depends on FB
|
|
help
|
|
This menu will let you enable support for the framebuffers with
|
|
non-native endianness (e.g. Little-Endian framebuffer on a
|
|
Big-Endian machine). Most probably you don't have such hardware,
|
|
so it's safe to say "n" here.
|
|
|
|
choice
|
|
prompt "Choice endianness support"
|
|
depends on FB_FOREIGN_ENDIAN
|
|
|
|
config FB_BOTH_ENDIAN
|
|
bool "Support for Big- and Little-Endian framebuffers"
|
|
|
|
config FB_BIG_ENDIAN
|
|
bool "Support for Big-Endian framebuffers only"
|
|
|
|
config FB_LITTLE_ENDIAN
|
|
bool "Support for Little-Endian framebuffers only"
|
|
|
|
endchoice
|
|
|
|
config FB_SYSMEM_FOPS
|
|
tristate
|
|
depends on FB_CORE
|
|
|
|
config FB_DEFERRED_IO
|
|
bool
|
|
depends on FB_CORE
|
|
|
|
config FB_DMAMEM_HELPERS
|
|
bool
|
|
depends on FB_CORE
|
|
select FB_SYS_COPYAREA
|
|
select FB_SYS_FILLRECT
|
|
select FB_SYS_IMAGEBLIT
|
|
select FB_SYSMEM_FOPS
|
|
|
|
config FB_DMAMEM_HELPERS_DEFERRED
|
|
bool
|
|
depends on FB_CORE
|
|
select FB_DEFERRED_IO
|
|
select FB_DMAMEM_HELPERS
|
|
|
|
config FB_IOMEM_FOPS
|
|
tristate
|
|
depends on FB_CORE
|
|
|
|
config FB_IOMEM_HELPERS
|
|
bool
|
|
depends on FB_CORE
|
|
select FB_CFB_COPYAREA
|
|
select FB_CFB_FILLRECT
|
|
select FB_CFB_IMAGEBLIT
|
|
select FB_IOMEM_FOPS
|
|
|
|
config FB_IOMEM_HELPERS_DEFERRED
|
|
bool
|
|
depends on FB_CORE
|
|
select FB_DEFERRED_IO
|
|
select FB_IOMEM_HELPERS
|
|
|
|
config FB_SYSMEM_HELPERS
|
|
bool
|
|
depends on FB_CORE
|
|
select FB_SYS_COPYAREA
|
|
select FB_SYS_FILLRECT
|
|
select FB_SYS_IMAGEBLIT
|
|
select FB_SYSMEM_FOPS
|
|
|
|
config FB_SYSMEM_HELPERS_DEFERRED
|
|
bool
|
|
depends on FB_CORE
|
|
select FB_DEFERRED_IO
|
|
select FB_SYSMEM_HELPERS
|
|
|
|
config FB_BACKLIGHT
|
|
bool
|
|
depends on FB
|
|
|
|
config FB_MODE_HELPERS
|
|
bool "Enable Video Mode Handling Helpers"
|
|
depends on FB
|
|
help
|
|
This enables functions for handling video modes using the
|
|
Generalized Timing Formula and the EDID parser. A few drivers rely
|
|
on this feature such as the radeonfb, rivafb, and the i810fb. If
|
|
your driver does not take advantage of this feature, choosing Y will
|
|
just increase the kernel size by about 5K.
|
|
|
|
config FB_TILEBLITTING
|
|
bool "Enable Tile Blitting Support"
|
|
depends on FB
|
|
help
|
|
This enables tile blitting. Tile blitting is a drawing technique
|
|
where the screen is divided into rectangular sections (tiles), whereas
|
|
the standard blitting divides the screen into pixels. Because the
|
|
default drawing element is a tile, drawing functions will be passed
|
|
parameters in terms of number of tiles instead of number of pixels.
|
|
For example, to draw a single character, instead of using bitmaps,
|
|
an index to an array of bitmaps will be used. To clear or move a
|
|
rectangular section of a screen, the rectangle will be described in
|
|
terms of number of tiles in the x- and y-axis.
|
|
|
|
This is particularly important to one driver, matroxfb. If
|
|
unsure, say N.
|