| Age | Commit message (Collapse) | Author |
|---|
|
The monochrome->color expansion routine that handles bitmaps which have
(widths % 8) != 0 (slow_imageblit) produces corrupt characters in big-endian.
This is caused by a bogus bit test in slow_imageblit().
Fix.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Acked-by: Herbert Poetzl <herbert@13thfloor.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
No need for a file argument. If we'd really need it it's in vma->vm_file
already. gbefb and sgivwfb used to set vma->vm_file to the file argument, but
the kernel alrady did that.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The ioctl and file arguments to ->fb_mmap are totally unused and there's not
reason a driver should need them.
Also update the ->fb_compat_ioctl prototype to be the same as ->fb_mmap.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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>
|
|
Every framebuffer driver relies on the assumption that the set_par()
function of the driver is called before drawing functions and other
functions dependent on the hardware state are executed.
Whenever you switch from X to a framebuffer console for the very first
time, there is a chance that a broken X system has _not_ set the mode to
KD_GRAPHICS, thus the vt and framebuffer code executes a screen redraw and
several other functions before a set_par() is executed. This is believed
to be not a bug of linux but a bug of X/xdm. At least some X releases used
by SuSE and Debian show this behaviour.
There was a 2nd case, but that has been fixed by Antonino Daplas on
10-dec-2005.
This patch allows drivers to set a flag to inform fbcon_switch() that they
prefer a set_par() call on every console switch, working around the
problems caused by the broken X releases.
The flag will be used by the next release of cyblafb and might help other
drivers that assume a hardware state different to the one used by X.
As the default behaviour does not change, this patch should be acceptable
to everybody.
Signed-off-by: Knut Petersen <Knut_Petersen@t-online.de>
Acked-by: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add hooks to save and restore the graphics state. These hooks are called in
fbcon_blank() when entering/leaving KD_GRAPHICS mode. This is needed by
savagefb at least so it can cooperate with savage_dri and by cyblafb.
State save/restoration can be full or partial.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add ability to set rotation via sysfs. The attributes are located in
/sys/class/graphics/fb[n] and accepts 0 - unrotated; 1 - clockwise; 2 - upside
down; 3 - counterclockwise.
The attributes are:
con_rotate (r/w) - set rotation of the active console
con_rotate_all (w) - set rotation of all consoles
rotate (r/w) - set rotation of the framebuffer, if supported.
Currently, none of the drivers support this.
This is probably temporary, since con_rotate and con_rotate_all are
console-specific and has no business being under the fb device. However,
until the console layer acquires it's own sysfs class, these attributes will
temporarily reside here.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add support for rotating and positioning of the logo. Rotation and position
depends on 'int rotate' parameter added to fb_prepare_logo() and
fb_show_logo().
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch series implements generic code to rotate the console at 90, 180,
and 270 degrees. The implementation is completely done in the framebuffer
console level, thus no changes to the framebuffer layer or to the drivers
are needed.
Console rotation is required by some Sharp-based devices where the natural
orientation of the display is not at 0 degrees. Also, users that have
displays that can pivot will benefit by having a console in portrait mode
if they so desire.
The choice to implement the code in the console layer rather than in the
framebuffer layer is due to the following reasons:
- it's fast
- it does not require driver changes
- it can coexist with devices that can rotate the display at the hardware level
- it complements graphics applications that can do display rotation
The changes to core fbcon are minimal-- recognition of the console
rotation angle so it can swap directions, origins and axes (xres vs yres,
xpanstep vs ypanstep, xoffset vs yoffset, etc) and storage of the rotation
angle per display. The bulk of the code that does the actual drawing to the
screen are placed in separate files. Each angle of rotation has separate
methods (bmove, clear, putcs, cursor, update_start which is derived from
update_var, and clear_margins). To mimimize processing time, the fontdata
are pre-rotated at each console switch (only if the font or the angle has
changed).
The option can be compiled out (CONFIG_FRAMEBUFFER_CONSOLE_ROTATION = n) if
rotation is not needed.
Choosing the rotation angle can be done in several ways:
1. boot option fbcon=rotate:n, where
n = 0 - normal
n = 1 - 90 degrees (clockwise)
n = 2 - 180 degrees (upside down)
n = 3 - 270 degrees (counterclockwise)
2. echo n > /sys/class/graphics/fb[num]/con_rotate
where n is the same as described above. It sets the angle of rotation
of the current console
3 echo n > /sys/class/graphics/fb[num]/con_rotate_all
where n is the same as described above. Globally sets the angle of
rotation.
GOTCHAS:
The option, especially at angles of 90 and 270 degrees, will exercise
the least used code of drivers. Namely, at these angles, panning is done
in the x-axis, so it can reveal bugs in the driver if xpanstep is set
incorrectly. A workaround is to set xpanstep = 0.
Secondly, at these angles, the framebuffer memory access can be
unaligned if (fontheight * bpp) % 32 ~= 0 which can reveal bugs in the drivers
imageblit, fillrect and copyarea functions. (I think cfbfillrect may have
this buglet). A workaround is to use a standard 8x16 font.
Speed:
The scrolling speed difference between 0 and 180 degrees is minimal,
somewhere areound 1-2%. At 90 or 270 degress, speed drops down to a vicinity
of 30-40%. This is understandable because the blit direction is across the
framebuffer "direction." Scrolling will be helped at these angles if xpanstep
is not equal to zero, use of 8x16 fonts, and setting xres_virtual >= xres * 2.
Note: The code is tested on little-endian only, so I don't know if it will
work in big-endian. Please let me know, it will take only less than a minute
of your time.
This patch prepares fbcon for console rotation and contains the following
changes:
- add rotate field in struct fbcon_ops to keep fbcon's current rotation
angle
- add con_rotate field in struct display to store per-display rotation angle
- create a private copy of the current var to fbcon. This will prevent
fbcon from directly manipulating info->var, especially the fields xoffset,
yoffset and vmode.
- add ability to swap pertinent axes (xres, yres; xpanstep, ypanstep; etc)
depending on the rotation angle
- change global update_var() (function that sets the screen start address)
as an fbcon method update_start. This is required because the axes, start
offset, and/or direction can be reversed depending on the rotation angle.
- add fbcon method rotate_font() which will rotate each character bitmap to
the correct angle of rotation.
- add fbcon boot option 'rotate' to select the angle of rotation at bootime.
Currently does nothing until all patches are applied.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add new helper, fb_find_best_display(), which will search the modelist for the
best mode for the attached display. This requires an EDID block that is
converted to struct fb_monspecs and a private modelist. The search will be
done in this manner:
- if 1st detailed timing is preferred, use that
- else if dimensions of the display are known, use that to estimate xres and
- else if modelist has detailed timings, use the first detailed timing
- else, use the very first entry from the modelist
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Currently the fb_find_nearest_mode() function finds a mode with screen
resolution closest to that described by the 'var' argument and with some
arbitrary refresh rate (eg. in the following sequence of refresh rates: 70 60
53 85 75, 53 is selected).
This patch fixes the function so that it looks for the closest mode as far as
both resolution and refresh rate are concerned. The function's first argument
is changed to fb_videomode so that the refresh rate can be specified by the
caller, as fb_var_screeninfo doesn't have any fields that could directly hold
this data.
Signed-off-by: Michal Januszewski <spock@gentoo.org>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
drivers that do not support hardware cursors is redundant. The soft_cursor
function is usable by all drivers because it is just a wrapper around
fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is
moved to the console directory.
Thus, drivers that do not support hardware cursors can leave the fb_cursor
field blank. For drivers that do, they can fill up this field with their own
version.
The end result is a smaller code size. And if the framebuffer console is not
loaded, module/kernel size is also reduced because the soft_cursor module will
also not be loaded.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
const-ify the font control structures and data, to make somewhat better
guarantees that these are not modified anywhere in the kernel.
Specifically for a kernel debugger to share this information from the
normal kernel code, such a guarantee seems rather desirable.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The function bit_putcs() in drivers/video/console/bitblit.c is becoming large.
Break it up into its component functions (bit_putcs_unaligned and
bit_putcs_aligned).
Incorporated fb_pad_aligned_buffer() optimization by Roman Zippel.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The Coordinated Video Timings (CVT) is the latest standard approved by VESA
concerning video timings generation. It addresses the limitation of GTF which
is designed mainly for CRT displays. CRT's have a high blanking requirement
(as much as 25% of the horizontal frame length) which artificially increases
the pixelclock. Digital displays, on the other hand, needs to conserve the
pixelclock as much as possible. The GTF also does not take into account the
different aspect ratios in its calculation.
The new function added is fb_find_mode_cvt(). It is called by fb_find_mode()
if it recognizes a mode option string formatted for CVT. The format is:
<xres>x<yres>[M][R][-<bpp>][<at-sign><refresh>][i][m]
The 'M' tells the function to calculate using CVT. On it's own, it will
compute a timing for CRT displays at 60Hz. If the 'R' is specified, 'reduced
blanking' computation will be used, best for flatpanels. The 'i' and the 'm'
is for 'interlaced mode' and 'with margins' respectively.
To determine if CVT was used, check for dmesg for something like this:
CVT Mode - <pix>M<n>[-R], ie: .480M3-R (800x600 reduced blanking)
where: pix - product of xres and yres, in MB
M - is a CVT mode
n - the aspect ratio (3 - 4:3; 4 - 5:4; 9 - 16:9, 15:9; A - 16:10)
-R - reduced blanking
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This lifts sisfb from version 1.7.17 to version 1.8.9. Changes include:
- Added support for XGI V3XT, V5, V8, Z7 chipsets, including POSTing of
all of these chipsets.
- Added support for latest SiS chipsets (761).
- Added support for SiS76x memory "hybrid" mode.
- Added support for new LCD resolutions (eg 1280x854, 856x480).
- Fixed support for 320x240 STN panels (for embedded devices).
- Fixed many HDTV modes (525p, 750p, 1080i).
- Fixed PCI config register reading/writing to use proper kernel
functions for this purpose.
- Fixed PCI ROM handling to use the kernel's proper functions.
- Removed lots of "typedef"s.
- Removed lots of code which was for X.org/XFree86 only.
- Fixed coding style in many places.
- Removed lots of 2.4 cruft.
- Reduced stack size by unifying two previously separate structs into
one.
- Added new hooks for memory allocation (for DRM). Now the driver can
truly handle multiple cards, including memory management.
- Fixed numerous minor bugs.
Signed-off-by: Thomas Winischhofer <thomas@winischhofer.net>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Currently, fbcon assumes that the visual FB_VISUAL_MONO* is always 1 bit.
According to Geert, there are old hardware where it's possible to have
monochrome at 8-bit, but has only 2 colors, black - 0x00 and white - 0xff.
Fix color handlers (fb_get_color_depth, and get_color) for this special case.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
For the i386, code is already present in video.S that gets the EDID from the
video BIOS. Make this visible so drivers can also use this data as fallback
when i2c does not work.
To ensure that the EDID block is returned for the primary graphics adapter
only, by check if the IORESOURCE_ROM_SHADOW flag is set.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add capability to fbdev to listen to the FB_ACTIVATE_ALL flag. If set, it
notifies fbcon that all consoles must be set to the current var.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Shrink the stack when calling the drawing alignment functions.
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Since no one is using the inbuf, outbuf of struct fb_pixmap I removed their
use in the framebuffer console. The idea is instead move the pixmap
functionality below the accelerated functions intead of on top as the way
it is now. If there is no objection please apply. This is against Linus
latestr GIT tree. Thank you.
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch adds to the fbdev interface a set_cmap callback that allow the
driver to "batch" palette changes. This is useful for drivers like
radeonfb which might require lenghtly workarounds on palette accesses, thus
allowing to factor out those workarounds efficiently.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
initialized
Accessing the hardware before it is properly initialized can lead to crashes
or screen corruption. This happens when switching to X then back to console.
When console comes back from X, the device is in an undefined state. During
this window, accessing the hardware is disallowed.
A new field in fbcon_par is added (graphics), which will be set to nonzero
just before initialization of the framebuffer and when coming back from
KD_GRAPHICS, then unset when an fb_set_var/fb_set_par is done. While this
field is set, no accesses to the hardware is done. The consequence of this
change is, hopefully, more robust switching between KD_GRAPHICS<-> KD_TEXT.
An added benefit coming from this change is that the MODESWITCHLATE hack is
not needed anymore and thus removed. This hack is used by savagefb, rivafb
and nvidiafb.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch contains cleanups including the following:
- make needlessly global code static
- remove the needlessly #ifdef MODULE from several module_exit
- remove or #if 0 the following unused global functions:
- fbmon.c: fb_create_modedb
- fbmon.c: fb_get_monitor_limits
- nvidia/nv_i2c.c: nvidia_delete_i2c_busses
- nvidia/nv_setup.c: NVEnablePalette
- nvidia/nv_setup.c: NVReadDacMask
- remove the following unneeded EXPORT_SYMBOL's:
- fbmon.c: fb_create_modedb
- fbmon.c: fb_get_monitor_limits
- hgafb.c: hgafb_setup
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add capability to change private modelist. It checks if the entries in the
new modelist are acceptable, and if not, trimmed from the modelist.
Also added a new event, FB_EVENT_NEW_MODELIST, sent by fbmem, and captured by
fbcon to resize all consoles, if need be.
Requires minor changes to new functions, ie, fb_get_color_depth().
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This is a first pass at adding two new sysfs attributes to
/sys/class/graphics/fb0 for setting modes. There are two attributes: modes
which contains a list of valid modes, and mode which is the current mode. To
switch modes echo one of the entries from the modes list to the mode
attribute.
The D,V,S on the modes represents Detailed, Vesa, Standard from the DDC info.
modes is root writable. It can also be used to set the list of modes. For
example a /etc file could add modes that are not in the monitor's DDC.
mode is user writable. PAM would set ownership of mode at user login time.
This provides a safe way for a user to set the mode without being root. You
can only set the mode to one of the modes on the list.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Because nVidia keeps pumping out new graphics chipsets, it is becoming
harder to add support for these with the old rivafb code. Currently, rivafb
can properly support NV_ARCH_20 chipsets and older.
Instead of rewriting rivafb to support the latest chipsets, I've decided to
write a new driver, called nvidiafb. The aim is to closely follow Xorg
development.
Currently, this driver is based on the most recent CVS Xorg nv driver. Main
- console acceleration for all chipsets
- uses DMA instead of PIO
- better LCD/digital output support
- better monitor detection
- support for Riva128 will be dropped as it cannot do DMA, rivafb
will remain as the driver for this chipset
It should work with Xorg/XFree86 nv driver, but as with rivafb, is not
compatible with the proprietary nvidia driver.
Once the code becomes stable, rivafb code will be trimmed to only support the
Riva128 and perhaps some of the older chipsets. The code has been tested on
several nVidia graphics card on x86 and x86_64. I'm still waiting for
feedback from Guido Guenther regarding ppc.
This need not go to mainline immediately, as I would prefer the code to
receive rigorous testing in the mm tree.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Fix some confusion over fbdev compat_ioctl return types - compat_ioctls return
`long'.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
From: Art Haas
The current GCC cvs code does not like the include/linux/fb.h file:
In file included from drivers/video/aty/atyfb_base.c:63:
include/linux/fb.h:865: error: array type has incomplete element type
This error is due to recent changes in GCC. A thread discussing this
change can be found by following the link below:
http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html
The patch moves the array declaration after the definition of the
fb_modelist structure, and with this small change GCC is happy once
again.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Forward compat_ioctl through the frame buffer layer.
Signed-off-by: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Add blanking event to the notifier call chain. This can be used by fbcon
to blank/unblank the console, and theoretically, by backlight drivers.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The VESA_* constants in fb.h used for power management of the display is
confusing to use. The constants seems to be meant for userspace, because
within the kernel (vt and fbdev), the constants have to be incremented by
1. Implementation of fb_blank() varies from driver to driver:
- if-else on blank/!blank
- switch case on hardcoded numbers
- switch case on the constants + 1
- switch -1, case on constants as is
- switch case on the constants as is (broken)
To make usage clearer, new constants are defined in fb.h:
FB_BLANK_UNBLANK = VESA_UNBLANKING = 0;
FB_BLANK_NORMAL = VESA_UNBLANKING + 1 = 1;
FB_BLANK_VSYNC_SUSPEND = VESA_VSYNC_SUSPEND + 1 = 2;
FB_BLANK_HSYNC_SUSPEND = VESA_HSYNC_SUSPEND + 1 = 3;
FB_BLANK_POWERDOWN = VESA_POWERDOWN + 1 = 4;
Other changes:
- generic blanking code in fbcon.c (for drivers without an fb_blank hook)
which either sets the palette to all black, or clear the screen with
black.
- make fb_display an unexportable symbol
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The following fields in struct fb_info is specific only to fbcon:
- struct timer_ cursor_timer
- int currcon
Remove them from struct fb_info and place them in fbcon_par so they become
invisible from the drivers.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
S3 Savage Frambuffer Driver for the following chipsets:
Savage 3D
Savage MX
Savage 4
Savage 2000
ProSavage
SuperSavage
This is based from the driver written by:
Denis Oliver Kropp <dok@directfb.org>
Sven Neumann <neo@directfb.org>
Initial Porting to 2.6 done by:
Mika Pruikkonen <mpruikko@cc.hut.fi>
Added the following:
- Console acceleration support (imageblit, fillrect, copyarea) -
Configurable
- DDC2/I2C support for (ProSavage DDR-K, Savage 4 and Prosavage PM only -
Configurable
- 8, 16, 32 bits per pixel
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Linux framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G integrated
graphics chips.
Port from kernel 2.4 + some modifications and cleanup :
- Fix HW accel on 845G
- Use of agpgart for fb memory reservation
- Add mtrr support
Signed-off-by: Sylvain Meyer <sylvain.meyer@worldonline.fr>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The current cursor interface is confusing. Some fields are taken from the
cursor structure in struct fb_info (enable, mask, rop fields) and the rest are
taken from the passed cursor structure. These lead to a lot of confusion,
making it hard for developers to write their own implementation.
Also, the cursor code has several 'short-circuits', occassionally leading to
undefined cursor behavior.
These are the changes brought about by the patch:
- Removed struct fb_cursor and related fields from struct fb_info, and
instead, placed them in a struct not visible to fbdev.
- The struct fb_cursor passed to fb_cursor() will _always_ contain valid
data with various bitflags indicating which fields have changed
- The struct fb_pixmap sprite in struct fb_info is used only by drivers with
hardware cursor implementation. Initializing and allocating memory for this
structure is not needed. Remove initialization and memory allocation.
- The FBIO_CURSOR ioctl is broken (because fb_cursor() is broken). For now,
remove fb_cursor code and make the FBIO_CURSOR ioctl always return -ENODEV.
- The flag FB_CUR_SETCUR is changed to FB_CUR_SETIMAGE, indicating that the
cursor sprite has changed. The image change is now checked by fbcon so
drivers will not unnecessarily load the sprite image everytime. This causes
hardware cursors to flicker, especially in rivafb.
- Remove fb_load_cursor_image(). This is unused, and should not be
implemented generically.
- Documented the usage of the cursor interface in skeletonfb.c
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Hopefully, this patch fixes one last major regression for one particular
driver, namely matroxfb. This drier has 2 versions, one for the kernel and
another as a '2.4 backport' patch.
This patch adds a tileblitting extension to fbcon. This extension, in
summary, is basically a forward-port of the 2.4 fbdev/fbcon framework to 2.6
but without the fbcon dependency. Tile blitting is similar to bitblit, except
that the basic unit is a tile (a bitmap of x-by-y dimensions). The display,
instead of being described in terms of pixels and scanlines, are described as
a region further subdivided into rectangular sections. In fbcon parlance, a
tile is a character.
Besides a possible fix for matroxfb, tileblitting can be advantageous for
hardware that supports some kind of fontcaching mechanism. Also, in the
unlikely chance that the console begins supporting multicolored fonts,
tileblitting is probably more optimal than bitblitting because bitblitting
will need to push more data through the bus.
To enable support for this extension, a driver needs to:
- enable CONFIG_FB_TILEBLITTING
- set FBINFO_MISC_TILEBLITTING in info->flags
- set the required function pointers in struct fb_tileops. The required
operations are:
- void (*fb_settile)(struct fb_info *info, struct fb_tilemap *map);
tells driver about the tile characteristics (dimensions, bitdepth) and
about the tilemap which is an array of bitmaps: display->fontdata
- void (*fb_tilecopy)(struct fb_info *info, struct fb_tilearea *area);
move a rectangular section of tiles (bmove)
- void (*fb_tilefill)(struct fb_info *info, struct fb_tilerect *rect);
fill a rectangular section with a tile (clear)
- void (*fb_tileblit)(struct fb_info *info, struct fb_tileblit *blit);
copy an array of tiles to a rectangular section (putcs)
- void (*fb_tilecursor)(struct fb_info *info, struct fb_tilecursor *cursor);
cursor function
Changes:
Addition of this extension necessitates cleanup of fbcon.c. The basic drawing
functions in fbcon are bmove, clear, putcs and cursor (the fbcon_* set). The
fbcon_* set are just wrappers to accel_* set. However, usage is not
consistent, some functions call the fbcon_* set, others call the accel_* set.
With this patch, a new fbcon-specific structure (struct fbcon_ops) is created.
Depending on the setting of the hardware, this struct contains pointers to
either the tileblitting set or the bitblitting set (formerly the accel_* set).
The tileblitting set is new in this patch.
The vast majority of functions in fbcon will need to only call the fbcon_*
set. In turn, it calls functions in struct fbcon_ops. Knowledge of the
blitting type is not required.
The accel_* set is renamed to bit_* and is moved into a separate file,
bitblit.c. The tile blitting set is in tileblit.c.
In my case at least, the cleanup did produce an unexpected but beneficial
side effect, a little more speedup. Not much, < 5%.
Petr, if you have comments, suggestions, or you think this is a bad idea,
let me know.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Swsusp turns off the display when a power-management-enabled framebuffer
driver is used. According to Nigel Cunningham <ncunningham@linuxmail.org>,
the fix may involve the following:
"...I thought the best approach would be to use device classes to find the
struct dev for the frame buffer driver, and then use the same code I use for
storage devices to avoid suspending the frame buffer until later..."
Changes:
- pass info->device to class_simple_device_add()
- add struct device *device to struct fb_info
- store struct device in framebuffer_alloc()
- for drivers not using framebuffer_alloc(), store the struct during
initalization
- port i810fb and rivafb to use framebuffer_alloc()
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Fix fbcon's setup routine so usage is consistent with previous kernels.
Ie: video=ofonly and video=xxxfb:off should work.
This is done by fb_get_options() returning a nonzero value if:
- 'off' option is present
- 'ofonly' is present but driver name is not 'offb'
All drivers will not proceed with their initialization if return value is
nonzero.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
From: Michal Januszewski <spock@gentoo.org>
"The latest changes introduced to the fb structs in linux/fb.h make
compilation of userspace programs break with:
include/linux/fb.h:305: error: field `modelist' has incomplete type
This is caused by struct list_head not being seen from userspace."
This patch removes struct list_head modelist from struct fb_monspecs and
moves it to struct fb_info instead, and for now, enclosed struct
fb_monspecs by #ifdef __KERNEL__/#endif.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch kills the bogus radeonfb_read/write routines. In order to do so,
it adds a new member to fb_info, along with screen_base, which is screen_size,
indicating the mapped area. The default fb_read/write will now use that instead
of fix->smem_len if it is non-0, and radeonfb now sets it to the mapped size
of the framebuffer.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
|
This patch probably deserves discussion among developers.
Currently, the framebuffer system is initialized in a roundabout manner.
First, drivers/char/mem.c calls fbmem_init(). fbmem_init() will then
iterate over an array of individual drivers' xxxfb_init(), then each driver
registers its presence back to fbmem. During console_init(),
drivers/char/vt.c will call fb_console_init(). fbcon will check for
registered drivers, and if any are present, will call take_over_console()
in drivers/char/vt.c.
This patch changes the initialization sequence so it proceeds in this
manner: Each driver has its own module_init(). Each driver calls
register_framebuffer() in fbmem.c. fbmem.c will then notify fbcon of the
driver registration. Upon notification, fbcon calls take_over_console() in
vt.c.
The following are the changes brought about by this patch:
- Each subsystem (fbcon, fbmem, xxxfb) will have their own module_init.
Thus, explicit calls to each subsystem's init functions are eliminated.
- The struct fb_drivers array in fbmem.c can be removed. This slashes
around 400 lines in fbmem.c
- Parsing of kernel boot options were done by fbmem.c calling each
driver's xxxfb_setup() function. Because this is not possible with this
patch, drivers can choose to either:
- have their own __setup() routine
- call fb_get_options("xxxfb") and pass the return value to
xxxfb_setup(). This is to maintain compatibility with the
'video=xxxfb:<options>' semantics.
- Getting a framebuffer console will occur a bit late during the boot
process since the initialization sequence will depend upon the link
order. So, 'video/' is moved up in drivers/Makefile, shortly after
'pci/'
- Because driver initialization will be dependent on the link order,
hardware that depends on other subsystems (agpgart, usb, serial, etc) may
choose to initialize after the subsystems they depend on.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
- This fixes another regression from 2.4. If fbcon is compiled
statically, and the framebuffer driver is compiled as a module, doing a
'modprobe xxxfb' does nothing to the console. This has generated
numerous bug reports from users.
With this patch, fbmem will notify fbcon upon driver registration
allowing fbcon to take over the console.
- This also fixes con2fbmap not working if fbcon is compiled as a module
using the same mechanism as described above.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch adds support for the bold attribute for monochrome framebuffers.
This fixes a regression from 2.4 where bold, underline and reverse
attributes are supported.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This is optional but applying it should enhance fbdev functionality.
The patch allows removal of entries to the mode list. This is done by setting
the var->activate field to FB_ACTIVATE_INV_MODE. Only modes that are not in
use by any of the console or by the current var will be deleted.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch adds the following:
a. convert struct fb_var_screeninfo to struct display and vice versa
b. save settings of graphics card to struct display
c. save settings of display to struct display as a pointer to a struct
fb_videomode
d. check var in fb_set_var for modes, and if unique, add them to the mode list.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
The patch adds support for a mode database in a linked list form.
Included in the patch are exportable functions that will:
a. convert struct fb_videomode to struct fb_var_screeninfo and vice versa
b. search the mode list for matching or best-fit modes
c. add/delete entries to the database
d. convert a mode array to a mode list
e. destroy the entire list
d. compare 2 modes
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
1. If you remember this thread (HP300 support checked in), one concern
was how to support framebuffers with bpp == 8 but color depth < 8
(chunky layout). I suggested to use the fields in var->{red|green|blue}
to differentiate between bits_per_pixel and depth. Included is a patch
that does that.
(The above assumes background/foreground of 0/1. If hardware needs a
different value, such as 0 - black, 0xff - white, just indicate
TRUECOLOR or DIRECTCOLOR and set info->pseudopalette correctly in
xxxfb_setcolreg().)
The patch will break the following drivers when in monochrome since
they do not set the proper color bitfields. I've included a fix in
patch #2.
68328fb
bw2fb
cirrusfb
dnfb
macfb
stifb
tx3912fb
2. Besides the change above, support for the inverse and underline
attribute is added in monochrome mode. One should get text which are
underlined/reversed if the corresponding attribute is set.
3. Because vt.c uses a 16-color palette, use fbcon_default_cmap if
framebuffer can do less than 16 colors. In 4 colors, display will be
grayscaled. In 8 colors, display should have the same colors as a
16-color console but will lack brightness/ intensity.
4. Fix monochrome logo drawing.
5. Reduce code of fbcon_putc so it just calls fbcon_putcs.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
fb_set_cmap() and fb_copy_cmap() split into kernel and userland versions.
fb_cmap, fb_image and fb_cursor split and annotated.
fixed bug in sbuslib.c that used to call "userland" version of fb_set_cmap()
when kernel one was need (RGB data was already copied into kernel space).
Signed-off-by: Al Viro <viro@parcelfarce.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
