err remains uninitialized of pci_request_regions fails.
Found by Thorsten Kukuk, I added a few more checks.
Signed-off-by: Olaf Hering <olh@suse.de>
Cc: "Antonino A. 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>
This updates the matroxfb code so that it can find the PInS data embedded
in the BIOS on PowerPC cards. The process for finding the data is
different on OpenFirmware cards than on x86 cards, and the code for doing
so was missing.
After patching, building, installing, and booting a kernel, you should grep
for "PInS" in /var/log/messages. You should see two messages in the log:
PInS data found at offset XXXXX
PInS memtype = X
On the GXT135p card I get "31168" and "5". The first value is irrelevant,
but it's presence lets me know that the PInS data was actually found. On a
GXT130p, the second value should be 3. Since I don't have access to that
hardware, if someone can verify that, I will submit a follow-on patch that
rips out all the memtype parameter stuff.
Signed-off-by: Ian Romanick <idr@us.ibm.com>
Signed-off-by: Petr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The link for ATI's product page in drivers/video/Kconfig for FB_RADEON is
broken. Replace with a product comparison page.
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, atyfb has code that sets the hsync and vsync polarity based on the
current video mode, without letting the user override the settings.
Remove this particular code. The sync polarities are set by the PROM, the
user or by the videomode.
Signed-off-by: Alexander Kern <alex.kern@gmx.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>
Currently, the default linux 16-colors are converted to 4-colors by simply
dividing the values by 4. However, this is not necessarily correct since the
first 4 colors are converted to black, rendering them invisible.
So, for black, no conversion; for light colors, convert to gray, for normal
text color, no conversion, and for bright colors, convert to intense white.
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, 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>
If nvidiafb fails to probe the EDID block, get the EDID from the BIOS.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- Fallback to firmware EDID if chipset has no DDC/I2C support or if I2C
probing failed
- Add fb_blank hook
- Fix savagefb_suspend/resume to enable driver to successfully suspend and
resume from S3, memory or disk
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>
Geode framebuffer driver updates:
- Local mode list (taken from modedb.c) containing only relevant modes.
This also makes the driver work as a module.
- Make it a PCI driver (from James Simmons <jsimmons@infradead.org>).
- A few other minor cosmetic bits and pieces.
Signed-off-by: David Vrabel <dvrabel@arcom.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes drivers that have hardware cursors from calling the
software cursor code. Also if the driver sets a no hardware cursor flag
then the driver reports a error it someone attempts to use the cursor.
Signed-off-by: James Simmons <jsimmons@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>
Add rudimentary support by manipulating the VGA registers. However, not
all vesa modes are VGA compatible, so VGA compatiblity is checked first.
Only 2 levels are supported, powerup and powerdown.
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>
Some people use 66-cells braille devices for reading the console, and hence
would like to reduce the width of the screen by using:
stty cols 66
However, the vga text console doesn't behave correctly: the 14 first
characters of the second line are put on the right of the first line and so
forth.
Here is a patch to correct that. It corrects the disp_end and offset
registers of the vga board on console resize and console switch.
On usual screens, you then correctly get a right and/or bottom blank
margin. On some laptop panels, the output is resized so that text actually
gets magnified, which can be great for some people (see
http://dept-info.labri.fr/~thibault/ls.jpg ).
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch pulls the PCI-related junk out of struct device_node and
puts it in a separate structure, struct pci_dn. The device_node now
just has a void * pointer in it, which points to a struct pci_dn for
nodes that represent PCI devices. It could potentially be used in
future for device-specific data for other sorts of devices, such as
virtual I/O devices.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The code w100fb was based on was horribly Sharp SL-C7x0 specific and there
was little else that could be done as I had no access to anything else with
a w100 in it. There is no real documentation about this chipset available.
Ian Molton has access to other platforms with the w100 (Toshiba e-series)
and so between us, we've improved w100fb and made it platform independent.
Ian Molton also added support for the very similar w3220 and w3200
chipsets.
There are a lot of changes here and it nearly amounts to a rewrite of the
driver but it has been extensively tested and is being used in preference
to the original driver in the Zaurus community. I'd therefore like to
update the mainline code to reflect this.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
asm/segment.h varies greatly on different architectures but is clearly
deprecated. Removing all non-architecture consumers will make it easier
for us to get ride of asm/segment.h all together.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds support for powering Zaurus's video up and down. PDA without
screen is kind of useless, so it is quite important... I'll have to figure
out how to really control the frontlight, because LCD without that is quite
hard to read.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In theory, there should be no more users of I2C_ALGO_* at this point.
However, it happens that several drivers were using I2C_ALGO_* for
adapter ids, so we need to correct these before we can get rid of all
the I2C_ALGO_* definitions.
Note that this also fixes a bug in media/video/tvaudio.c:
/* don't attach on saa7146 based cards,
because dedicated drivers are used */
if ((adap->id & I2C_ALGO_SAA7146))
return 0;
This test was plain broken, as it would succeed for many more adapters
than just the saa7146: any those id would share at least one bit with
the saa7146 id. We are really lucky that the few other adapters we want
this driver to work with did not fulfill that condition.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Merge the algorithm id part (16 upper bits) of the i2c adapters ids
into the definition of the adapters ids directly. After that, we don't
need to OR both ids together for each i2c_adapter structure.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This adds type-checking to pm_message_t, so that people can't confuse it
with int or u32. It also allows us to fix "disk yoyo" during suspend (disk
spinning down/up/down).
[We've tried that before; since that cpufreq problems were fixed and I've
tried make allyes config and fixed resulting damage.]
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix remaining bits of u32 vs. pm_message confusion. Should not break
anything.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: Pavel Kysilka (Bugzilla Bug 5059)
The intelfb driver does not keep resolution set with fbset after
switching to anot console and back.
Steps to reproduce:
initial options: tty1,tty2 - 1024x768-60
1) tty1 - fbset after booting (1024x768-60)
2) tty1 - fbset 800x600-100
tty1: 800x600-100
3) swith to tty2, swith to tty1
tty1: 1024x768-60 (the same resolution as default from kernel booting)
This bug is caused by intelfb unintentionally destroying info->flags in
set_par(). Therefore the flag, FBINFO_MISC_USEREVENT used to notify
fbcon of a mode change was cleared causing the above problem. This bug
though is not intelfb specific, as other drivers may also be affected.
The fix is to save info->flags in a local variable before calling any
of the driver hooks. A more definitive fix (for post 2.6.13) is to
separate info->flags into one that is set by the driver and another that
is set by core fbdev/fbcon.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: Pavel Kysilka (Bugzilla Bug 4738)
modprobe of intelfb results in the following error message:
intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G chi
intelfb: Version 0.9.2
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
allocation failed: out of vmalloc space - use vmalloc=<size> to increase siz
intelfb: Cannot remap FB region.
This will fail if the graphics aperture size is greater than 128 MB.
Fix is to ioremap only from the beginning of graphics aperture to the
end of the used framebuffer memory.
Signed-off-by: Sylvain Meyer <sylvain.meyer@worldonline.fr>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by:Vincent Fortier (Bugzilla Bug 4768)
"At boot time the screen appears moved to the mid right portion of the actual
video pannel making the end of the line appears at the left edge... It simply
looks like moved half way to the right"
His particular hardware has a display with an unusual dimension (1920x1200) but
unfortunately has no EDID block. None of the entries in the global mode
database is correct for this particular display, and it particularly has
difficulty scaling up 640x480 (the default startup mode of nvidiafb) to
1920x1200 which causes the above described problem.
1, Add 1920x1200 to the global mode database.
2. Let nvidiafb base the startup mode from the flatpanel dimensions only if the
EDID block is absent, no boot mode parameter is specified by the user, and
a flatpanel/LCD display is attached.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This function produces a warning when CPU_FREQ=n. Since it's a very
simple calculation, make it inline instead of adding preprocessor
directives around it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reported by: Jochen Hein (Bugzilla Bug 4312)
When there is disk I/O happening, the framebuffer has a little snow on
the screen. Once I/O has finished, no garbage remains on screen.
This bug was explained by: Knut Petersen
Most important is CRTC register 2f, signal quality is also improved for
higher vclk values by changing set_vclk() according to the X drivers and
cyblafb.c
The fix is to set the performance register (0x2f) with a more stable
value.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: Jochen Hein (Bugzilla Bug 4386)
booting leaves the end of long lines in the last line on screen when
scrolling. When X is running, scrolling puts garbage on the screen
(looks like X data) Console switch fixes the screen. Behaviour seems to
be identical with noaccel and without on the video=tridentfb parameter
in lilo.conf.
This bug was explained by: Knut_Petersen
Acceleration is broken for all BLADE 3D chips for all versions of kernel
2.6 except for 32bit modes. Most important reason is that the u32 col
parameter of the graphics engine needs the color value replicated to all
u8 of the u32 (8bit modes) and to both u16 of the u32.
Fix color value passed to graphics engine, verified by the reporter.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch displays the name of the fbdev driver in sysfs.
Down the road this will replace the current proc handle we have.
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Do not use memcpy in fb_pad_aligned_buffer. It is suboptimal because only
a few bytes are moved at a time. Replace with a for-loop.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
>> vesafb: mode is 800x600x16, linelength=1600, pages=16
>> vesafb: scrolling: redraw
>> vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
>> mtrr: type mismatch for fc000000,1000000 old: write-back new: write-
>> combining
Range is already set to write-back, vesafb attempts to add a write-combining
mtrr (default for vesafb).
>> mtrr: size and base must be multiples of 4 kiB
This is a bug, vesafb attempts to add a size < PAGE_SIZE triggering
the messages below.
To eliminate the warning messages, you can add the option mtrr:2 to add a
write-back mtrr for vesafb. Or just use nomtrr option.
1. Fix algorithm for finding the best power of 2 size with mtrr_add().
2. Add option to choose the mtrr type by extending the mtrr boot option:
mtrr:n where n
0 = no mtrr (equivalent to using the nomtrr option)
1 = uncachable
2 = write back
3 = write combining (default)
4 = write through
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
`gcc -W' likes to complain if the static keyword is not at the beginning of
the declaration. This patch fixes all remaining occurrences of "inline
static" up with "static inline" in the entire kernel tree (140 occurrences in
47 files).
While making this change I came across a few lines with trailing whitespace
that I also fixed up, I have also added or removed a blank line or two here
and there, but there are no functional changes in the patch.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The fb_info struct, as defined in include/linux/fb.h, contains an element
that is supposed to hold the current color map:
struct fb_cmap cmap; /* Current cmap */
This cmap is currently never updated when either fb_set_cmap() or
fb_set_user_cmap() are called. As a result, info->cmap contains the
default cmap that was set by a device driver/fbcon and a userspace
application using the FBIOGETCMAP ioctl will not always get the *currently*
used color map.
The patch fixes this by making sure the cmap is copied to info->cmap after
it is set correctly. It moves most of the code that is responsible for
setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to avoid
code-duplication.
Signed-off-by: Michal Januszewski <spock@gentoo.org>
Cc: <linux-fbdev-devel@lists.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently even when the cursor is disabled (`setterm -cursor off`), it is
still repainted as a black rectangle the size of a single char. This can
be seen, for example, by chvt'ing to a free tty, disabling the cursor and
doing `dd if=3D/dev/urandom of=3D/dev/fb0`.
The patch changes this behaviour by avoiding painting anything when the
cursor is disabled.
Signed-off-by: Michal Januszewski <spock@gentoo.org>
Cc: <linux-fbdev-devel@lists.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Color maps have up to 256 entries. 4096/256 allows for 16 characters per
line. The format for a cmap entry is "%02x%c%4x%4x%4x\n" %02x entry %c
transp %4x red %4x blue %4x green
You can read the color_map with cat fb0/color_map.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
radeonfb does not clean up EDID sysfs attribute
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
fbdev is missing unregister_chrdev() on unload.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix rounding error when mode frequency is very close to monitor limit
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
turn many #if $undefined_string into #ifdef $undefined_string to fix some
warnings after -Wno-def was added to global CFLAGS
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
arch/mips/Kconfig is defining CONFIG_FB as bool and drivers/video/Kconfig
was changed a while ago to define it as tristate. Remove the MIPS
definition.
Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>