* [BK FBDEV updates]
@ 2003-01-08 19:19 ` James Simmons
0 siblings, 0 replies; 8+ messages in thread
From: James Simmons @ 2003-01-08 19:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Fbdev development list, Linux Kernel Mailing List
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:
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [BK FBDEV updates]
@ 2003-01-08 19:19 ` James Simmons
0 siblings, 0 replies; 8+ messages in thread
From: James Simmons @ 2003-01-08 19:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Fbdev development list, Linux Kernel Mailing List
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:
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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.
<jsimmons@maxwell.earthlink.net> (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
^ permalink raw reply [flat|nested] 8+ messages in thread
* 2.5 fbdev & driver initial mode
2003-01-08 19:19 ` James Simmons
(?)
@ 2003-01-08 21:52 ` Benjamin Herrenschmidt
2003-01-09 0:32 ` James Simmons
-1 siblings, 1 reply; 8+ messages in thread
From: Benjamin Herrenschmidt @ 2003-01-08 21:52 UTC (permalink / raw)
To: James Simmons; +Cc: Linux Fbdev development list
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.5 fbdev & driver initial mode
2003-01-08 21:52 ` 2.5 fbdev & driver initial mode Benjamin Herrenschmidt
@ 2003-01-09 0:32 ` James Simmons
2003-01-09 9:30 ` Geert Uytterhoeven
0 siblings, 1 reply; 8+ messages in thread
From: James Simmons @ 2003-01-09 0:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux Fbdev development list
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: 2.5 fbdev & driver initial mode
2003-01-09 0:32 ` James Simmons
@ 2003-01-09 9:30 ` Geert Uytterhoeven
2003-01-09 10:39 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 8+ messages in thread
From: Geert Uytterhoeven @ 2003-01-09 9:30 UTC (permalink / raw)
To: James Simmons; +Cc: Benjamin Herrenschmidt, Linux Fbdev development list
On Thu, 9 Jan 2003, James Simmons wrote:
> > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: 2.5 fbdev & driver initial mode
2003-01-09 9:30 ` Geert Uytterhoeven
@ 2003-01-09 10:39 ` Benjamin Herrenschmidt
2003-01-09 20:34 ` James Simmons
0 siblings, 1 reply; 8+ messages in thread
From: Benjamin Herrenschmidt @ 2003-01-09 10:39 UTC (permalink / raw)
To: Geert Uytterhoeven
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Re: 2.5 fbdev & driver initial mode
2003-01-09 10:39 ` Benjamin Herrenschmidt
@ 2003-01-09 20:34 ` James Simmons
0 siblings, 0 replies; 8+ messages in thread
From: James Simmons @ 2003-01-09 20:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, Geert Uytterhoeven,
Linux Frame Buffer Device Development, Linux Kernel Mailing List
> > 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Linux-fbdev-devel] Re: 2.5 fbdev & driver initial mode
@ 2003-01-09 20:34 ` James Simmons
0 siblings, 0 replies; 8+ messages in thread
From: James Simmons @ 2003-01-09 20:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, Geert Uytterhoeven,
Linux Frame Buffer Device Development, Linux Kernel Mailing List
> > 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-01-09 20:34 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-08 19:19 [BK FBDEV updates] James Simmons
2003-01-08 19:19 ` James Simmons
2003-01-08 21:52 ` 2.5 fbdev & driver initial mode Benjamin Herrenschmidt
2003-01-09 0:32 ` James Simmons
2003-01-09 9:30 ` Geert Uytterhoeven
2003-01-09 10:39 ` Benjamin Herrenschmidt
2003-01-09 20:34 ` [Linux-fbdev-devel] " James Simmons
2003-01-09 20:34 ` James Simmons
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.