Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James S. <jsi...@in...> - 2002-10-29 21:14:50
|
> On Tue, Oct 29, 2002 at 12:45:10PM -0800, James Simmons wrote: > > The reason for this is we will see in the future embedded ix86 > > boards with things like i810 framebuffers with NO vga core. In this case > > we will need a fbdev driver for a graphical console. Thus the agp code > > must be started before the fbdev layer. > > Can you explain exactly what the agpgart code is doing that needs > to be done earlier than framebuffer ? I don't see any reason for this > change. There should be no GART mappings until we've booted userspace > (except for the case of IOMMU) The reason I did this was to prevent adding another chuck of agp code. The current work around for AGP fbdev drivers to have there OWN AGP code. So we can leave the agp drivers where they are at or the framebuffer layer can have its own AGP code for itself. Which way do you think it should be done? 1) Fbdev layer has it own AGP layer 2) Use already existing AGP layer code. |
|
From: Christoph H. <hc...@in...> - 2002-10-29 20:55:42
|
On Tue, Oct 29, 2002 at 12:46:16PM -0800, James Simmons wrote: > > OOps. Forgot the link. > > bk://fbdev.bkbits.net/fbdev-2.5 Does it still contain the random file movearounds? |
|
From: Dave J. <da...@co...> - 2002-10-29 20:09:53
|
On Tue, Oct 29, 2002 at 12:45:10PM -0800, James Simmons wrote: > The reason for this is we will see in the future embedded ix86 > boards with things like i810 framebuffers with NO vga core. In this case > we will need a fbdev driver for a graphical console. Thus the agp code > must be started before the fbdev layer. Can you explain exactly what the agpgart code is doing that needs to be done earlier than framebuffer ? I don't see any reason for this change. There should be no GART mappings until we've booted userspace (except for the case of IOMMU) Dave -- | Dave Jones. http://www.codemonkey.org.uk |
|
From: James S. <jsi...@in...> - 2002-10-29 19:53:05
|
OOps. Forgot the link. bk://fbdev.bkbits.net/fbdev-2.5 Thank you. |
|
From: James S. <jsi...@in...> - 2002-10-29 19:52:03
|
Hi!!!
Here are the last series of fbdev changes. The console layer code has
been removed from the low level drivers. This it is possible to run fbdev
without the VT console system or with it using a different driver. I did
this with the VESA fbdev driver and MDA con!!!! This will save so much
time testing future fbdev drivers.
I also moved the agp and drm code over to drivers/video. The reason I
did this was to support fbdev drivers that will be strickly DMA/AGP
based. The reason for this is we will see in the future embedded ix86
boards with things like i810 framebuffers with NO vga core. In this case
we will need a fbdev driver for a graphical console. Thus the agp code
must be started before the fbdev layer.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsi...@us...] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
|
|
From: Nicholas W. <nw...@ne...> - 2002-10-29 14:14:20
|
Ani Joshi wrote: > > radeonfb for 2.5 will be updated in the next release (or 2). > > Ping? =) Cheers, Nicholas |
|
From: James S. <jsi...@in...> - 2002-10-28 23:31:48
|
Hi folks!!! After several lonng days of syncing up my new console code I'm nearly done. Unfortunely I have let the code code rot while it sat in Dave Jones tree. So I have updates it but now it has several bugs. Tonight I'm going to track them done but if people like to try this new code out and help me track the new bugs I would be very happy. You can grab the latest code via bitkeeper at bk://linuxconsole.bkbits.net/stable. I will make a diff in the next few hours. Thank you. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Stephane W. <ste...@be...> - 2002-10-28 12:25:34
|
Hi ! KERNEL : 2.5.44 Here is a compile error with the frame buffer and the rivafb. drivers/video/riva/fbdev.c: In function `riva_set_dispsw': drivers/video/riva/fbdev.c:665: structure has no member named `type' drivers/video/riva/fbdev.c:666: structure has no member named `type_aux' drivers/video/riva/fbdev.c:667: structure has no member named `ypanstep' drivers/video/riva/fbdev.c:668: structure has no member named `ywrapstep' drivers/video/riva/fbdev.c:686: structure has no member named `line_length' drivers/video/riva/fbdev.c:687: structure has no member named `visual' drivers/video/riva/fbdev.c:695: structure has no member named `line_length' drivers/video/riva/fbdev.c:696: structure has no member named `visual' drivers/video/riva/fbdev.c: In function `rivafb_setcolreg': drivers/video/riva/fbdev.c:1202: warning: unused variable `chip' drivers/video/riva/fbdev.c: In function `rivafb_get_fix': drivers/video/riva/fbdev.c:1294: structure has no member named `type' drivers/video/riva/fbdev.c:1295: structure has no member named `type_aux' drivers/video/riva/fbdev.c:1296: structure has no member named `visual' drivers/video/riva/fbdev.c:1302: structure has no member named `line_length' drivers/video/riva/fbdev.c: In function `rivafb_pan_display': drivers/video/riva/fbdev.c:1611: structure has no member named `line_length' drivers/video/riva/fbdev.c: At top level: drivers/video/riva/fbdev.c:1748: unknown field `fb_get_fix' specified in initializer drivers/video/riva/fbdev.c:1748: warning: initialization from incompatible pointer type drivers/video/riva/fbdev.c:1749: unknown field `fb_get_var' specified in initializer drivers/video/riva/fbdev.c:1749: warning: initialization from incompatible pointer type drivers/video/riva/fbdev.c:732: warning: `riva_wclut' defined but not used make[3]: *** [drivers/video/riva/fbdev.o] Error 1 make[2]: *** [drivers/video/riva] Error 2 make[1]: *** [drivers/video] Error 2 make: *** [drivers] Error 2 stef@stargate ~/kernel/linux-2.5.44 -- 13:26 Best regards Stephane Wirtel -- Stephane Wirtel <ste...@be...> GPG ID : 1024D/C9C16DA7 | 5331 0B5B 21F0 0363 EACD B73E 3D11 E5BC C9C1 6DA7 |
|
From: Geert U. <ge...@li...> - 2002-10-23 14:47:00
|
On Wed, 23 Oct 2002, Martin Schulze wrote:
> Geert Uytterhoeven wrote:
> > On Sat, 19 Oct 2002, Martin Schulze wrote:
> > > please apply the patch below which will add proper handling for
> > > monochrome graphic cards.
> > >
> > > Both changes are required since there are graphic cards out in the
> > > voi^Wwild that are monochrome but have bits_per_pixel set to something
> > > else than 1, e.g. PMAG-AA which uses 8 bits per pixel but ignores 7 of
> > > it.
> > >
> > > Since currently no such card is supported, this change wasn't
> > > required. However, we developed support for the PMAG-AA card and we
> > > would like to add support for it to the Linux kernel, of course.
> >
> > HP300 TopCat uses a similar scheme, and is supported by Linux/m68k.
>
> *cough* Is there a working machine running Linux out somewhere? If
> so, I wonder why this oddity wasn't noted/didn't appear etc.
drivers/video/hpfb.c sets fb_var_screeninfo.bits_per_pixel to 1 instead of 8,
and relies on an unmerged[*] hack to drivers/video/fbcon.c to display the
monochrome penguin logo.
> HP300 is not a really working port iirc.
Yes, it depends a lot on your definition of `working' :-)
Gr{oetje,eeting}s,
Geert
[*] Available from Linux/m68k CVS http://linux-m68k-cvs.apia.dhs.org/
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Geert U. <ge...@li...> - 2002-10-23 14:15:30
|
---------- Forwarded message ----------
Date: Wed, 23 Oct 2002 16:12:39 +0200 (MEST)
From: Geert Uytterhoeven <ge...@li...>
To: Martin Schulze <jo...@in...>
Cc: Ralf Baechle <ra...@li...>,
Linux/MIPS Development <lin...@li...>
Subject: Re: [patch] Correct monochrome selection
On Sat, 19 Oct 2002, Martin Schulze wrote:
> please apply the patch below which will add proper handling for
> monochrome graphic cards.
>
> Both changes are required since there are graphic cards out in the
> voi^Wwild that are monochrome but have bits_per_pixel set to something
> else than 1, e.g. PMAG-AA which uses 8 bits per pixel but ignores 7 of
> it.
>
> Since currently no such card is supported, this change wasn't
> required. However, we developed support for the PMAG-AA card and we
> would like to add support for it to the Linux kernel, of course.
HP300 TopCat uses a similar scheme, and is supported by Linux/m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Geert U. <ge...@li...> - 2002-10-23 14:15:18
|
---------- Forwarded message ----------
Date: Sat, 19 Oct 2002 19:05:34 +0200
From: Martin Schulze <jo...@in...>
To: Ralf Baechle <ra...@li...>
Cc: lin...@li...
Subject: [patch] Correct monochrome selection
Hi Ralf,
please apply the patch below which will add proper handling for
monochrome graphic cards.
Both changes are required since there are graphic cards out in the
voi^Wwild that are monochrome but have bits_per_pixel set to something
else than 1, e.g. PMAG-AA which uses 8 bits per pixel but ignores 7 of
it.
Since currently no such card is supported, this change wasn't
required. However, we developed support for the PMAG-AA card and we
would like to add support for it to the Linux kernel, of course.
Regards,
Joey
Index: fbcon.c
===================================================================
RCS file: /home/cvs/linux/drivers/video/fbcon.c,v
retrieving revision 1.28.2.4
diff -u -r1.28.2.4 fbcon.c
--- fbcon.c 2 Oct 2002 13:28:31 -0000 1.28.2.4
+++ fbcon.c 19 Oct 2002 16:57:40 -0000
@@ -711,7 +711,8 @@
if ((p->var.yres % fontheight(p)) &&
(p->var.yres_virtual % fontheight(p) < p->var.yres % fontheight(p)))
p->vrows--;
- conp->vc_can_do_color = p->var.bits_per_pixel != 1;
+ conp->vc_can_do_color = (p->fb_info->fix.visual != FB_VISUAL_MONO10 &&
+ p->fb_info->fix.visual != FB_VISUAL_MONO01);
conp->vc_complement_mask = conp->vc_can_do_color ? 0x7700 : 0x0800;
if (charcnt == 256) {
conp->vc_hi_font_mask = 0;
@@ -2177,7 +2178,12 @@
p->fb_info);
}
- if (depth >= 8) {
+ if (p->visual == FB_VISUAL_MONO10 ||
+ p->visual == FB_VISUAL_MONO01) {
+ logo = linux_logo_bw;
+ logo_depth = 1;
+ }
+ else if (depth >= 8) {
logo = linux_logo;
logo_depth = 8;
}
--
Every use of Linux is a proper use of Linux. -- Jon "Maddog" Hall
|
|
From: Geert U. <ge...@li...> - 2002-10-23 14:15:04
|
Any comments?
---------- Forwarded message ----------
Date: Sat, 19 Oct 2002 18:50:54 +0200
From: Martin Schulze <jo...@in...>
To: Ralf Baechle <ra...@li...>
Cc: lin...@li...
Subject: [patch] Correct colour handling
Moin Ralf,
please apply the patch below which will correct colour handling. The
outcome of this patch will only be visible with a monochrome graphics
card since they can see what is written on the screen again.
As you can see, not all occasions where the currently used colour is
changed, isn't protected by the 'if (can_do_color)' check. Some
occurrences though use it.
This patch is done basically by Thiemo Seufer during this years'
Oldenburg meeting.
Regards,
Joey
Index: console.c
===================================================================
RCS file: /home/cvs/linux/drivers/char/console.c,v
retrieving revision 1.37.2.2
diff -u -r1.37.2.2 console.c
--- console.c 26 Jun 2002 22:35:32 -0000 1.37.2.2
+++ console.c 19 Oct 2002 16:47:01 -0000
@@ -1046,7 +1046,8 @@
underline = 0;
reverse = 0;
blink = 0;
- color = def_color;
+ if (can_do_color)
+ color = def_color;
}
/* console_sem is held */
@@ -1119,7 +1120,8 @@
* with white underscore (Linux - use
* default foreground).
*/
- color = (def_color & 0x0f) | background;
+ if (can_do_color)
+ color = (def_color & 0x0f) | background;
underline = 1;
break;
case 39: /* ANSI X3.64-1979 (SCO-ish?)
@@ -1127,11 +1129,13 @@
* Reset colour to default? It did this
* before...
*/
- color = (def_color & 0x0f) | background;
+ if (can_do_color)
+ color = (def_color & 0x0f) | background;
underline = 0;
break;
case 49:
- color = (def_color & 0xf0) | foreground;
+ if (can_do_color)
+ color = (def_color & 0xf0) | foreground;
break;
default:
if (par[i] >= 30 && par[i] <= 37)
@@ -1274,9 +1278,11 @@
}
break;
case 8: /* store colors as defaults */
- def_color = attr;
- if (hi_font_mask == 0x100)
- def_color >>= 1;
+ if (can_do_color) {
+ def_color = attr;
+ if (hi_font_mask == 0x100)
+ def_color >>= 1;
+ }
default_attr(currcons);
update_attr(currcons);
break;
--
Every use of Linux is a proper use of Linux. -- Jon "Maddog" Hall
|
|
From: Geert U. <ge...@li...> - 2002-10-22 19:07:25
|
On Fri, 18 Oct 2002, James Simmons wrote:
> fb_rastering: I don't know if we are going to keep this one?
AFAIK these are used by the SPARC people only, to switch the graphics hardware
to frame buffer mode so the logo can be drawn. All other operations are done
using the accel engine on the cards that need fb_rasterimg().
So yes, once the logo is drawn by fb_imageblit(), fb_rasterimg() can be
eliminated by moving its functionality inside the fbdev-specific
fb_imageblit().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Geert U. <ge...@li...> - 2002-10-22 17:15:22
|
On Fri, 18 Oct 2002, Russell King wrote:
> On Fri, Oct 18, 2002 at 02:24:48PM -0700, James Simmons wrote:
> > Your right. That is a bug from the old fbgen code. Since few driver used
> > the old fbgen code it never appeared. I suggest we remove can_soft_blank
> > and just test to see if the function pointer exist for fb_blank. If it
> > doesn't then we can resort to other tricks in suggested in the ther email.
>
> Ok. What about the case where you're running in true colour / static
> pseudo colour, and can't blank the palette, but do have a fb_blank
> method to handle the direct colour / pseudo colour case?
That's what the return value of the fb_blank() function is for: to indicate
whether it handled the blanking or not. If not, the upper layer has to take
care of it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Jani M. <ja...@iv...> - 2002-10-21 07:33:41
|
> Give it a try. For people who want a diff it is avaiable at > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Is there a newer one maybe against 2.5.44? The above deleted char/Config.in and video/Config.in and possibly lacked other files... |
|
From: Joachim S. <ro...@hy...> - 2002-10-21 01:46:06
|
since i was asked a few times to use a sgi1600sw flatpanel with multilink adapter with aty128fb at full resolution at boot time i made a small patch against 2.4.17-pre8 some time ago you can get it here: http://reactor.hyte.de/~roh/patches/aty128fb-sgi1600sw-resolution.diff the aty is (in my case still) connected via analog-vga to the multilink-adapter the timings are 'borrowed' from the output of the dcc-module from xfree at starting time the resolution is set to 1600x1024pixels, the bpp default is 16(565) the patch also applies to 2.4.19 with a small offset in one hunk i saw something about merging atyfb, aty128fb and radeonfb some time on a mailinglist... how far is the process done? is there the possibility to make things like working ddc-detection and automatic calculation of timings from that information a working option? regards roh ps: mail me if you have any questions regarding this hardware-combination |
|
From: Ben P. <bl...@cs...> - 2002-10-20 02:25:37
|
Here's a patch, along the lines of the differences between vesafb
between 2.4.19 and 2.5.44, that makes vga16fb work for me under
2.5.x. I don't get a penguin at boot-up, but I don't get one
with vesafb either, and everything else seems to work.
--- linux-2.5.44/drivers/video/vga16fb.c 2002-10-18 21:01:19.000000000 -0700
+++ linux-2.5.44-work/drivers/video/vga16fb.c 2002-10-19 17:04:32.000000000 -0700
@@ -22,6 +22,7 @@
#include <linux/selection.h>
#include <linux/ioport.h>
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <asm/io.h>
@@ -81,22 +82,33 @@
/* --------------------------------------------------------------------- */
static struct fb_var_screeninfo vga16fb_defined = {
- 640,480,640,480,/* W,H, W, H (virtual) load xres,xres_virtual*/
- 0,0, /* virtual -> visible no offset */
- 4, /* depth -> load bits_per_pixel */
- 0, /* greyscale ? */
- {0,0,0}, /* R */
- {0,0,0}, /* G */
- {0,0,0}, /* B */
- {0,0,0}, /* transparency */
- 0, /* standard pixel format */
- FB_ACTIVATE_NOW,
- -1,-1,
- 0,
- 39721, 48, 16, 39, 8,
- 96, 2, 0, /* No sync info */
- FB_VMODE_NONINTERLACED,
- {0,0,0,0,0,0}
+ .xres = 640,
+ .yres = 480,
+ .xres_virtual = 640,
+ .yres_virtual = 480,
+ .bits_per_pixel = 4,
+ .activate = FB_ACTIVATE_NOW,
+ .height = -1,
+ .width = -1,
+ .pixclock = 39721,
+ .left_margin = 48,
+ .right_margin = 16,
+ .upper_margin = 39,
+ .lower_margin = 8,
+ .hsync_len = 96,
+ .vsync_len = 2,
+ .vmode = FB_VMODE_NONINTERLACED,
+};
+
+static struct fb_fix_screeninfo vga16fb_fix __initdata = {
+ .id = "VGA16 VGA",
+ .smem_start = VGA_FB_PHYS,
+ .smem_len = VGA_FB_PHYS_LEN,
+ .type = FB_TYPE_VGA_PLANES,
+ .visual = FB_VISUAL_PSEUDOCOLOR,
+ .xpanstep = 8,
+ .ypanstep = 1,
+ .line_length = 640 / 8,
};
static struct display disp;
@@ -121,69 +133,22 @@
#endif
}
-static int vga16fb_update_var(int con, struct fb_info *info)
-{
- vga16fb_pan_var(info, &fb_display[con].var);
- return 0;
-}
-
-static int vga16fb_get_fix(struct fb_fix_screeninfo *fix, int con,
- struct fb_info *info)
-{
- struct display *p;
-
- if (con < 0)
- p = &disp;
- else
- p = fb_display + con;
-
- memset(fix, 0, sizeof(struct fb_fix_screeninfo));
- strcpy(fix->id,"VGA16 VGA");
-
- fix->smem_start = VGA_FB_PHYS;
- fix->smem_len = VGA_FB_PHYS_LEN;
- fix->type = FB_TYPE_VGA_PLANES;
- fix->visual = FB_VISUAL_PSEUDOCOLOR;
- fix->xpanstep = 8;
- fix->ypanstep = 1;
- fix->ywrapstep = 0;
- fix->line_length = p->var.xres_virtual / 8;
- return 0;
-}
-
-static int vga16fb_get_var(struct fb_var_screeninfo *var, int con,
- struct fb_info *info)
-{
- if(con==-1)
- memcpy(var, &vga16fb_defined, sizeof(struct fb_var_screeninfo));
- else
- *var=fb_display[con].var;
- return 0;
-}
-
static void vga16fb_set_disp(int con, struct vga16fb_info *info)
{
- struct fb_fix_screeninfo fix;
- struct display *display;
-
- if (con < 0)
- display = &disp;
- else
- display = fb_display + con;
+ struct display *display = (con < 0) ? info->fb_info.disp : (fb_display + con);
-
- vga16fb_get_fix(&fix, con, &info->fb_info);
-
- display->visual = fix.visual;
- display->type = fix.type;
- display->type_aux = fix.type_aux;
- display->ypanstep = fix.ypanstep;
- display->ywrapstep = fix.ywrapstep;
- display->line_length = fix.line_length;
- display->next_line = fix.line_length;
display->can_soft_blank = 1;
+ display->dispsw_data = NULL;
+ display->var = info->fb_info.var;
display->inverse = 0;
+ /*
+ * If we are setting all the virtual consoles, also set
+ * the defaults used to create new consoles.
+ */
+ if (con < 0 || info->fb_info.var.activate & FB_ACTIVATE_ALL)
+ info->fb_info.disp->var = info->fb_info.var;
+
if (info->isVGA)
display->dispsw = &fbcon_vga_planes;
else
@@ -500,13 +465,9 @@
{
struct vga16fb_info *info = (struct vga16fb_info*)fb;
struct vga16fb_par par;
- struct display *display;
+ struct display *display = (con < 0) ? fb->disp : (fb_display + con);
int err;
- if (con < 0)
- display = fb->disp;
- else
- display = fb_display + con;
if ((err = vga16fb_decode_var(var, &par, info)) != 0)
return err;
vga16fb_encode_var(var, &par, info);
@@ -552,25 +513,6 @@
outb_p(0x20, 0x3C0); /* unblank screen */
}
-static int vga16_getcolreg(unsigned regno, unsigned *red, unsigned *green,
- unsigned *blue, unsigned *transp,
- struct fb_info *fb_info)
-{
- /*
- * Read a single color register and split it into colors/transparent.
- * Return != 0 for invalid regno.
- */
-
- if (regno >= 16)
- return 1;
-
- *red = palette[regno].red;
- *green = palette[regno].green;
- *blue = palette[regno].blue;
- *transp = 0;
- return 0;
-}
-
static void vga16_setpalette(int regno, unsigned red, unsigned green, unsigned blue)
{
outb(regno, dac_reg);
@@ -615,19 +557,6 @@
return 0;
}
-static int vga16fb_get_cmap(struct fb_cmap *cmap, int kspc, int con,
- struct fb_info *info)
-{
- if (con == info->currcon) /* current console? */
- return fb_get_cmap(cmap, kspc, vga16_getcolreg, info);
- else if (fb_display[con].cmap.len) /* non default colormap? */
- fb_copy_cmap(&fb_display[con].cmap, cmap, kspc ? 0 : 2);
- else
- fb_copy_cmap(fb_default_cmap(16),
- cmap, kspc ? 0 : 2);
- return 0;
-}
-
static int vga16fb_pan_display(struct fb_var_screeninfo *var, int con,
struct fb_info *info)
{
@@ -811,10 +740,8 @@
static struct fb_ops vga16fb_ops = {
.owner = THIS_MODULE,
- .fb_get_fix = vga16fb_get_fix,
- .fb_get_var = vga16fb_get_var,
.fb_set_var = vga16fb_set_var,
- .fb_get_cmap = vga16fb_get_cmap,
+ .fb_get_cmap = gen_get_cmap,
.fb_set_cmap = gen_set_cmap,
.fb_setcolreg = vga16fb_setcolreg,
.fb_pan_display =vga16fb_pan_display,
@@ -839,27 +766,6 @@
return 0;
}
-static int vga16fb_switch(int con, struct fb_info *fb)
-{
- struct vga16fb_par par;
- struct vga16fb_info *info = (struct vga16fb_info*)fb;
-
- /* Do we have to save the colormap? */
- if (fb_display[fb->currcon].cmap.len)
- fb_get_cmap(&fb_display[fb->currcon].cmap, 1, vga16_getcolreg,
- fb);
-
- fb->currcon = con;
- vga16fb_decode_var(&fb_display[con].var, &par, info);
- vga16fb_set_par(&par, info);
- vga16fb_set_disp(con, info);
-
- /* Install new colormap */
- do_install_cmap(con, fb);
-/* vga16fb_update_var(con, fb); */
- return 1;
-}
-
int __init vga16fb_init(void)
{
int i,j;
@@ -895,19 +801,22 @@
disp.var = vga16fb_defined;
- /* name should not depend on EGA/VGA */
- strcpy(vga16fb.fb_info.modename, "VGA16 VGA");
+ strcpy(vga16fb.fb_info.modename, vga16fb_fix.id);
vga16fb.fb_info.changevar = NULL;
vga16fb.fb_info.node = NODEV;
+ vga16fb.fb_info.var = vga16fb_defined;
+ vga16fb.fb_info.fix = vga16fb_fix;
vga16fb.fb_info.fbops = &vga16fb_ops;
vga16fb.fb_info.screen_base = vga16fb.video_vbase;
vga16fb.fb_info.disp=&disp;
vga16fb.fb_info.currcon = -1;
- vga16fb.fb_info.switch_con=&vga16fb_switch;
- vga16fb.fb_info.updatevar=&vga16fb_update_var;
+ vga16fb.fb_info.switch_con=&gen_switch;
+ vga16fb.fb_info.updatevar=&gen_update_var;
vga16fb.fb_info.flags=FBINFO_FLAG_DEFAULT;
vga16fb_set_disp(-1, &vga16fb);
+ fb_alloc_cmap(&vga16fb.fb_info.cmap, 16, 0);
+
if (register_framebuffer(&vga16fb.fb_info)<0) {
iounmap(vga16fb.video_vbase);
return -EINVAL;
--
Aim to please, shoot to kill.
|
|
From: Antonino D. <ad...@po...> - 2002-10-19 11:05:03
|
On Sat, 2002-10-19 at 00:47, James Simmons wrote: > > > It looks like that nobody is interested in VGA anymore. Are there > > any objections against patch below? It is for current 2.5.42-bk, > > and it fixes vga16fb compilability, and adds -depth 8 (to get 320x200, or > > 360x480 in planar mode) and -depth 0 (to get fast textmode) to the vga16fb. > > I'm working on it. > > > If there are no objections, I'll split it up and send to Linus. But as > > Wait. I have your work already in the fbdev BK tree. I'm porting it to the > new api. I just need to write up a fillrect and copy area function for vga > planes mode. > I have a fillrect, copyarea and imageblit for vga16 since it was one of the first drivers I tested with the new framework. If you're too busy, you may want to use them instead. Never posted it because I don't want to preempt Petr. Tony |
|
From: Antonino D. <ad...@po...> - 2002-10-18 22:31:48
|
On Sat, 2002-10-19 at 05:19, James Simmons wrote: > > > Hi James, > > > > Since you seem to be very busy, here's an idea for the framebuffer > > cursor API. > > I looked over your patch and even tested it out. Then I thought about it a > long time. The question I had to ask myself is what do we want when we > have fbdev stand alone and fbdev with framebuffer console. Also how to use > a little code as possible (for embedded systems). So the goals are True, that's why the main bulk of the code is in fbcon.c and fbcon-accel.c. The driver specific method, fbops->fb_cursor, will only need to do the minimum, show and display the cursor. How it wants to display the cursor does not matter, it can choose to just display a simple rectangle, ignoring most fields in fbcursor, or use the entire gamut of information passed by fbcursor to display the correct attributes of the cursor. gen_cursor is just fallback. > > 1) For stand alone fbdev we want the maximum support for a cursor. But > what if we don't have a hardware cursor. In this case we should leave > it to userland to handle making it own cursor. The userland app might > not even want a cursor. So we avoid having extra code in the kernel for > a software cursor. I completely agree with you on this. > > 2) For fbcon the only thing we need for a cursor is a little rectangle. We > could still use imageblit but is seems really heavy when you consider > saving a bitmap of the current text under the cursor. True you have a > cost at reading the framebuffer when using fillrect but doesn't it cost > also to save the text bitmap under the cursor as well ? The question is > which cost more. > Actually the cost of getting the current text under the cursor is not expensive. It's just a pointer to the current character in display->fontdata. This is extra information which can be completely ignored if the hardware can do the inversion itself. Whether we use fillrect or imageblit is a matter of preference. For one, fillrect is definitely slower with ROP_XOR than with ROP_COPY (14 seconds vs .256 secs). Secondly, I just thought that imageblit is more flexible than fillrect. Also, usage of imageblit, which implies the presence of a bitmap, is more appropriate for hardware cursors that require the usage of some form of bitmap. The bitmap will only be loaded into memory if FB_CUR_SETSIZE and FB_CUR_SETSHAPE flags are set (change in fontsize and shape), so it will not be very expensive. My goal was to make the cursor behave correctly, and at the same time, minimize driver-specific code. I was actually surprised when the cursor did what it was supposed to do when I followed some of the examples in linux/Documentation/VGA-Softcursor.txt. This is just a suggestion. Tony PS: Is the "final update" patch for fbdev ready? I downloaded it once, but it just deleted most of the files :) |
|
From: Nicholas W. <nw...@ne...> - 2002-10-18 22:15:40
|
Antonino Daplas wrote: > Not necessarily painless... > > Given timings in X modeline format (you can generate with xvidtune): > > "XRESxYRES" MHZ XACTIVE FP_X HSYNC BP_X YACTIVE FP_Y VSYNC > BP_Y +hsync +vsync > > Then timings in fb.mode: > > mode "XRESxYRES MHZ" > # D: "MHZ, H: HorizSync kHz, V: VertRefresh Hz > geometry xres yres vxres vyres bpp > timings pixclock left right upper lower hsync vsync > hsync high > vsync high > endmode > > where: > > pixclock = 1000000/MHZ > left = BP_X - HSYNC > right = FP_X - XACTIVE > upper = BP_Y - VSYNC > lower = FP_Y - YACTIVE > hsync = HSYNC - FP_X > vsync = VSYNC - FP_Y > > What you need to concentrate on is the timings field of fb.modes. This > also assumes that the driver actually reads the timings field. Some > drivers disregard those values (considers only xres and yres) then > configure their own timings. > Tony, Thank you, this is *exactly* what I was looking for! I never knew what xvidtune was really for, but this sure answers that one. Cheers, Nicholas |
|
From: Antonino D. <ad...@po...> - 2002-10-18 21:47:12
|
On Thu, 2002-10-17 at 04:55, Nicholas Wourms wrote:
> B) Does anyone have a painless, yet precise way of
> generating modelines for fb.modes if you are using
> XFree-4.2? I only ask because the XFree modelines are all
> determined by i2c DDC probing, thus there are none in the
> XF86Config file. The modeline output captured in the log
> XFree.0.log is not the same output which modeline2fb
> expects. Anyhow, I've tried using some of the information
> in the log, but I always get funky results. I may be
> looking in the wrong place, but the documentation for both
> the fbdev kernel drivers and the X drivers are sorely out of
> date, so please excuse me if this is a question that has
> previously been answered. I just need some formulae to
> convert values between what shows up in XFree.0.log when i2c
> DDC probes for the modelines and what needs to go in
> fb.modes. Thanks in advance!
>
Not necessarily painless...
Given timings in X modeline format (you can generate with xvidtune):
"XRESxYRES" MHZ XACTIVE FP_X HSYNC BP_X YACTIVE FP_Y VSYNC
BP_Y +hsync +vsync
Then timings in fb.mode:
mode "XRESxYRES MHZ"
# D: "MHZ, H: HorizSync kHz, V: VertRefresh Hz
geometry xres yres vxres vyres bpp
timings pixclock left right upper lower hsync vsync
hsync high
vsync high
endmode
where:
pixclock = 1000000/MHZ
left = BP_X - HSYNC
right = FP_X - XACTIVE
upper = BP_Y - VSYNC
lower = FP_Y - YACTIVE
hsync = HSYNC - FP_X
vsync = VSYNC - FP_Y
What you need to concentrate on is the timings field of fb.modes. This
also assumes that the driver actually reads the timings field. Some
drivers disregard those values (considers only xres and yres) then
configure their own timings.
Tony
|
|
From: Russell K. <rm...@ar...> - 2002-10-18 21:37:17
|
On Fri, Oct 18, 2002 at 02:24:48PM -0700, James Simmons wrote:
> Your right. That is a bug from the old fbgen code. Since few driver used
> the old fbgen code it never appeared. I suggest we remove can_soft_blank
> and just test to see if the function pointer exist for fb_blank. If it
> doesn't then we can resort to other tricks in suggested in the ther email.
Ok. What about the case where you're running in true colour / static
pseudo colour, and can't blank the palette, but do have a fb_blank
method to handle the direct colour / pseudo colour case?
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@in...> - 2002-10-18 21:31:36
|
> > Yes the drivers should always have priority. The other stuff is there > > only if the drivers have no power management of any kind. I leave it up to > > the driver write to implement a fb_blank function that handles different > > cases. > > The drivers don't have priority though. You call set_par, and then > wander off into the internals of fbgen.c to set can_soft_blank youself, > without giving the drivers any look-in to set that correctly. Your right. That is a bug from the old fbgen code. Since few driver used the old fbgen code it never appeared. I suggest we remove can_soft_blank and just test to see if the function pointer exist for fb_blank. If it doesn't then we can resort to other tricks in suggested in the ther email. |
|
From: James S. <jsi...@in...> - 2002-10-18 21:26:12
|
> Hi James, > > Since you seem to be very busy, here's an idea for the framebuffer > cursor API. I looked over your patch and even tested it out. Then I thought about it a long time. The question I had to ask myself is what do we want when we have fbdev stand alone and fbdev with framebuffer console. Also how to use a little code as possible (for embedded systems). So the goals are 1) For stand alone fbdev we want the maximum support for a cursor. But what if we don't have a hardware cursor. In this case we should leave it to userland to handle making it own cursor. The userland app might not even want a cursor. So we avoid having extra code in the kernel for a software cursor. 2) For fbcon the only thing we need for a cursor is a little rectangle. We could still use imageblit but is seems really heavy when you consider saving a bitmap of the current text under the cursor. True you have a cost at reading the framebuffer when using fillrect but doesn't it cost also to save the text bitmap under the cursor as well ? The question is which cost more. |
|
From: Nicholas W. <nw...@ne...> - 2002-10-18 20:53:22
|
Michel Dänzer wrote: >> >> B) Does anyone have a painless, yet precise way of >> >> generating modelines for fb.modes if you are using >> >> XFree-4.2? I only ask because the XFree modelines are all >> >> determined by i2c DDC probing, thus there are none in the >> >> XF86Config file. >> > >> > If the X driver supports Option "UseFBDev", you should be able to use >> > fbset with that. >> > >> >> Huh? The problem is that fbset will not work because I need to populate >> fb.modes with proper mode lines. So at the moment fbset won't work at >> all. > > I was thinking of running X with Option "UseFBDev" and getting > information about the modes with fbset. > Hmm... I guess that setting doesn't do what I thought it did. I'll give it a shot and see if it works. Thanks! Cheers, Nicholas |
754 messages has been excluded from this view by a project administrator.
