From: James Simmons <hidden> Date: 2003-01-08 19:10:56
Linus, please do a
bk pull http://fbdev.bkbits.net:8080/fbdev-2.5
This will update the following files:
include/video/font.h | 24
arch/m68k/kernel/m68k_defs.c | 2
drivers/video/Kconfig | 2
drivers/video/Makefile | 3
drivers/video/aty/atyfb_base.c | 4
drivers/video/console/Kconfig | 14
drivers/video/console/fbcon.c | 90 +-
drivers/video/console/sticon.c | 101 +-
drivers/video/console/sticore.c | 159 ++--
drivers/video/fbmem.c | 13
drivers/video/fbmon.c | 369 ++++++++++
drivers/video/i810/i810.h | 2
drivers/video/i810/i810_accel.c | 11
drivers/video/i810/i810_dvt.c | 2
drivers/video/i810/i810_main.c | 51 -
drivers/video/i810/i810_main.h | 79 --
drivers/video/riva/Makefile | 2
drivers/video/riva/fbdev.c | 1468 +++++++++++++++++++---------------------
drivers/video/riva/nv_driver.c | 212 +++++
drivers/video/riva/riva_hw.c | 350 +++++++--
drivers/video/riva/rivafb.h | 15
drivers/video/sstfb.c | 711 +++++++++----------
drivers/video/sstfb.h | 31
drivers/video/sticore.h | 58 -
drivers/video/stifb.c | 103 ++
include/linux/fb.h | 4
include/linux/font.h | 30
27 files changed, 2337 insertions(+), 1573 deletions(-)
through these ChangeSets:
[off-list ref] (03/01/08 1.887)
[MONITOR support] GTF support for VESA complaint monitors. Here we calculate the general timings needed so we don't over step the bounds for a monitor.
[fbmem.c cleanup] Name change to make teh code easier to read.
[off-list ref] (03/01/07 1.879.2.95)
Updates from Helge Deller for the console/fbdev drivers for the PARISC platform. Small fix for clearing the screen and a string typo for the Voodoo 1/2 driver.
[off-list ref] (03/01/06 1.879.2.93)
[RIVA FBDEV] Driver now uses its own fb_open and fb_release function again. It has no ill effects. The drivers uses strickly hardware acceleration so we don't need cfb_fillrect and cfb_copyarea.
Cleaned up font.h. Geerts orignal pacth broke them up into a font.h in video and one in linux. Now I put them back together again in include/linux. The m68k platform has been updated for this change.
[off-list ref] (03/01/06 1.879.2.92)
Added resize support for the framebuffer console. Now you can change the console size via stty. Also support for color palette changing on VC switch is supported.
[off-list ref] (03/01/06 1.879.2.91)
I810 fbdev updates. Cursor fix for ati mach 64 cards on big endian machines. Buffer over flow fix for fbcon putcs function. C99 initializers for the STI console drivers.Voodoo 1/2 and NVIDIA driver updates.
The diff is located at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-01-08 22:04:37
Hi James !
How is a driver supposed to set the default mode on init lately ?
Looking at rivafb, it fills info->var from fb_find_mode with the mode
option if any, but then does nothing with it (and does nothing if
no mode option is passed).
On radeonfb, I fill a var with the default mode obtained
from EDID or the option if any. Then, I basically do
info->var = var;
var.activate = FB_ACTIVATE_NOW;
fb_set_var(&var, info);
before calling register_framebuffer.
What is the right way to do ?
Ben.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: James Simmons <hidden> Date: 2003-01-09 00:33:15
How is a driver supposed to set the default mode on init lately ?
Looking at rivafb, it fills info->var from fb_find_mode with the mode
option if any, but then does nothing with it (and does nothing if
no mode option is passed).
On radeonfb, I fill a var with the default mode obtained
from EDID or the option if any. Then, I basically do
info->var = var;
var.activate = FB_ACTIVATE_NOW;
fb_set_var(&var, info);
before calling register_framebuffer.
What is the right way to do ?
Sorry about the confusion. The answer depends on the driver. For the
rivafb driver because it has a VGA core we have it NOT switch to a
graphics state. The reason is
1) If we run a /dev/fb app was can save the hardware text mode state and
restore it on closing /dev/fb. You can see this in rivafb_open and
rivafb_release.
2) We can test loading it as a module as see debugging info while still
having a VGA text mode. Makes life a little easier. The other thing
I like to do is run mdacon and just the fbdev driver by itself. I can
then test the fbdev driver. When I get really brave I test fbcon.c and
can debug it.
Now for graphics hardware built in that has no hardware text mode. It is
better to set the video mode right away.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
How is a driver supposed to set the default mode on init lately ?
Looking at rivafb, it fills info->var from fb_find_mode with the mode
option if any, but then does nothing with it (and does nothing if
no mode option is passed).
On radeonfb, I fill a var with the default mode obtained
from EDID or the option if any. Then, I basically do
info->var = var;
var.activate = FB_ACTIVATE_NOW;
fb_set_var(&var, info);
before calling register_framebuffer.
What is the right way to do ?
Sorry about the confusion. The answer depends on the driver. For the
rivafb driver because it has a VGA core we have it NOT switch to a
graphics state. The reason is
1) If we run a /dev/fb app was can save the hardware text mode state and
restore it on closing /dev/fb. You can see this in rivafb_open and
rivafb_release.
2) We can test loading it as a module as see debugging info while still
having a VGA text mode. Makes life a little easier. The other thing
I like to do is run mdacon and just the fbdev driver by itself. I can
then test the fbdev driver. When I get really brave I test fbcon.c and
can debug it.
Now for graphics hardware built in that has no hardware text mode. It is
better to set the video mode right away.
Note: on some platforms graphics chips with VGA cores are _not_ initialized to
VGA mode by the firmware. So great care should be taken when not explicitly
switching to graphics mode on those platforms.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-01-09 10:39:20
On Thu, 2003-01-09 at 10:30, Geert Uytterhoeven wrote:
Note: on some platforms graphics chips with VGA cores are _not_ initialized to
VGA mode by the firmware. So great care should be taken when not explicitly
switching to graphics mode on those platforms.
Yup. This is typically the case of PowerMacs where the VGA memory isn't
even reachable on the PCI/AGP bus.
Ben.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
From: James Simmons <hidden> Date: 2003-01-09 20:26:18
quoted
Note: on some platforms graphics chips with VGA cores are _not_ initialized to
VGA mode by the firmware. So great care should be taken when not explicitly
switching to graphics mode on those platforms.
Yup. This is typically the case of PowerMacs where the VGA memory isn't
even reachable on the PCI/AGP bus.
Here are the case we will have.
1) Embedded devices. People here have a tendency to want to use serial
console and just want fbdev without fbcon. Fbcon set the graphics state
in fbcon_startup. Now the developers want to know if the hardware
actually worked. So they can call fb_set_var and fb_show_logo
themselves in there drivers. They want to fully bring up the hardware.
2) Now say the above want to use fbcon. Then they don't need to set the
graphics state in there driver. Fbcon will do it for them.
3) The graphics card has some kind of default text mode state. For the
case where we want to use /dev/fb without fbcon and the text mode then
we don't want to change the graphics state in the intialization code.
It is done in the first open and the last close.