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-12-11 05:40:37
|
> > When I look at atyfb_check_var or aty128fb_check_var, I see that they > > will alter the contents of *info->par. Isn't this a bad thing? My > > Yes, this wrong, and afaik, it's your original port to 2.5 that did that > ;) Yeap. The idea of check_var is to validate a mode. Note modedb uses just check_var. It is okay to READ the values in your par. You shouldn't alter the values in par. > > understanding was that after calling check_var, you don't necessarily > > call set_par next (particularly if check_var returned an error). Correct. Check_var is always called. Now if you wanted to just test a mode via userland with the FB_ACTIVATE_TEST flag then only fb_check_var is called. If you pass in FB_ACTIVATE_NOW then both fb_check_var and fb_set_par will be called. Fb_set_par actually sets the hardware state. > > Also I notice that atyfb_set_par and aty128fb_set_par don't look at > > info->var, they simply set the hardware state based on the contents of > > *info->par. > > Which is wrong too indeed Actually you can look at info->var. Info->var has been validated so it can be trusted. You don't need to stuff everything into par. You DO need to change info->fix if the hardware state has changed. > > Looking at skeletonfb.c, it seems that this is the wrong behaviour. I > > had fixed the aty128fb.c driver in the linuxppc-2.5 tree. James, if > > you let me know whether the current behaviour is wrong or not, I'll > > fix them and send you the patch. I hope me input helped. BTW docs are on the way. I will work with Steven Luther on this the next couple of days. > I _think_ my radeonfb (in linuxppc-2.5) is right in this regard too. > Look at the initialization too, iirc, you had some non necessary stuff > in there (calling gen_set_disp, gen_set_var is plenty enough). You go the logic down. P.S For the pmu_sleep_notifier can you pass in a specific struct fb_info or do you need to make a list of all of them? |
|
From: James S. <jsi...@in...> - 2002-12-11 05:26:42
|
> AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev. > Marc Aurele La France (maintainer of this driver) is basically allergic > to kernel fbdev support. :-( > I don't know if happened with earlier fbdev versions for you, but one > possibility is that X reconfigures the display base, and possibly more > bits of the card's internal memory map. Either fbdev should restore > that, or adapt to what X set. On R128's and radeon's, this is things > like DISPLAY_BASE_ADDR. I will have to go threw the X code to fix that :-( > > I have also tried aty128fb with some local patches to get it to > > compile for my G4 powerbook. It also doesn't draw the penguin, and it > > oopses when X starts, for some reason. > > Hrm... I'll have to test radeonfb... It worked yesteday in console (I > don't remember about the penguin) but I didn't try X. No penguin. That is weird. I get the penguin on my ix86 box. |
|
From: James S. <jsi...@in...> - 2002-12-11 05:07:55
|
> Here's a diff to correct several small things that escaped through the
> cracks.
Ug. Now that a wider test base is being done and more drivers actually
compile we are going to see more cracks.
> 1. The YNOMOVE scrollmode for non-accelerated drivers is just very slow
> because of a lot of block moves (leads to slow and jerky scrolling in
> vesafb with ypanning enabled). Depending on var->accel_flags, set the
> scrollmode to either YREDRAW or YNOMOVE. For drivers with hardware
> acceleration, set var->accel_flags to nonzero for max speed.
Thanks. I have had several emails complementing the speed improvements.
Another speed boost will be a plus.
> 2. fb_pan_display() always returns an error. User apps will complain.
Fixed. Actually I used the following code.
int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
{
int xoffset = var->xoffset;
int yoffset = var->yoffset;
int err;
if (xoffset < 0 || yoffset < 0 || info->fbops->fb_pan_display ||
xoffset + info->var.xres > info->var.xres_virtual ||
yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
if ((err = info->fbops->fb_pan_display(var, info)))
return err;
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
if (var->vmode & FB_VMODE_YWRAP)
instead. The reason is I didn't like the idea of xoffset and yoffset being
changed even if the hardware panning function failed. Comments?
> 3. case FBIO_GETCMAP in fb_ioctl does not return immediately. User
> apps will complain.
Fixed.
> 4. vgastate.c is not saving the correct blocks.
Fixed.
> 5. logo drawing for monochrome displays is just incorrect.(alterations
> were done by eyeballing only, no hardware for testing).
Will test on hgafb driver.
|
|
From: James S. <jsi...@in...> - 2002-12-11 04:56:04
|
> I have tried getting rivafb to work in 2.5.51. It is much better > than before (thanks!). It compiles and sorta works. Ug. Now that several drivers compile now I get bug reports :-( I'm getting alot of positive feedback as well as one negative source. > Here are the problems: > > When I run "fbset -a 640x480", I get display that fills > the screen and looks okay, but most of the characters are > flipped along the vertical axis, so they are backwards, so that: > > +---- ----+ > | | > +--- becomes ---+ > | | > | | Okay. That is weird. I have this card so I will give it a try. > Also, when I boot, the penguin logo looks like it is being rendered > in about five colors. Yipes. Imageblit sounds broken. > In addition, the text is black, except for > the white underscore cursor, so all I can see is the cursor. I noticed this. The color palette is for some reason messed up. > When the gpm gets loaded, the mouse pointer, instead of showing > a white rectangle that, when it passes over a character, shows that > character in reverse-video, shows a colored cursor that always > contains some character. The character shown in the mouse cursor > changes when it passes over text in the window, but it never shows > the character it is passing over. Same things. Color palette is messed up. > Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows > a usable console window, but it is embedded in the larger high > resolution display, like this: > > +---------+----------------+ > | | | > | | | > | | | > +---------+ | > | | > | | > | | > | | > | | > +--------------------------+ > > The area outside of the 640x480 boundary is filled with colored > junk (no characters). > > Any ideas? Yeap. I migrated changing the console from /dev/fb to actually using the tty layer. I haven't merged those changes yet but you will be able to do a stty -f /dev/ttyX 80 col 50 row and change the video mode. So I didn't plan to push so soon but I kept getting emails about various drivers being broken. So I did this push to make more drivers work. Unfortuenly I sent a watered down fbcon system. |
|
From: Miles L. <mil...@at...> - 2002-12-11 00:39:49
|
Hi, I have tried getting rivafb to work in 2.5.51. It is much better than before (thanks!). It compiles and sorta works. Here are the problems: When I run "fbset -a 640x480", I get display that fills the screen and looks okay, but most of the characters are flipped along the vertical axis, so they are backwards, so that: +---- ----+ | | +--- becomes ---+ | | | | Also, when I boot, the penguin logo looks like it is being rendered in about five colors. In addition, the text is black, except for the white underscore cursor, so all I can see is the cursor. When the gpm gets loaded, the mouse pointer, instead of showing a white rectangle that, when it passes over a character, shows that character in reverse-video, shows a colored cursor that always contains some character. The character shown in the mouse cursor changes when it passes over text in the window, but it never shows the character it is passing over. Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows a usable console window, but it is embedded in the larger high resolution display, like this: +---------+----------------+ | | | | | | | | | +---------+ | | | | | | | | | | | +--------------------------+ The area outside of the 640x480 boundary is filled with colored junk (no characters). Any ideas? Miles |
|
From: Benjamin H. <be...@ke...> - 2002-12-10 23:11:13
|
On Tue, 2002-12-10 at 23:40, Paul Mackerras wrote: > When I look at atyfb_check_var or aty128fb_check_var, I see that they > will alter the contents of *info->par. Isn't this a bad thing? My Yes, this wrong, and afaik, it's your original port to 2.5 that did that ;) > understanding was that after calling check_var, you don't necessarily > call set_par next (particularly if check_var returned an error). > Also I notice that atyfb_set_par and aty128fb_set_par don't look at > info->var, they simply set the hardware state based on the contents of > *info->par. Which is wrong too indeed > Looking at skeletonfb.c, it seems that this is the wrong behaviour. I > had fixed the aty128fb.c driver in the linuxppc-2.5 tree. James, if > you let me know whether the current behaviour is wrong or not, I'll > fix them and send you the patch. I _think_ my radeonfb (in linuxppc-2.5) is right in this regard too. Look at the initialization too, iirc, you had some non necessary stuff in there (calling gen_set_disp, gen_set_var is plenty enough). Ben. > Paul. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ |
|
From: Benjamin H. <be...@ke...> - 2002-12-10 23:08:10
|
On Tue, 2002-12-10 at 23:31, Paul Mackerras wrote: > I tried 2.5.51 on my G3 powerbook (laptop), which has a Rage LT Pro > video chip (ID 0x4c49 or LI). With the patch below, atyfb compiles > and seems to mostly work. However, I didn't see any penguin on boot. > Instead the top inch or so of the screen was just black. > > X seems to be running just fine. I have 'Option "UseFBDev"' in my > /etc/X11/XF86Config-4. AFAIK, the X "mach64" driver in XF 4.* doesn't care about UseFBDev. Marc Aurele La France (maintainer of this driver) is basically allergic to kernel fbdev support. > What doesn't work is changing VTs from X to a > text console. If I press ctrl-alt-F1, for instance, the colormap > changes but I don't see anything get redrawn. The screen looks just > like what I had in X but with the altered colormap. If I then press > alt-F7, it switches back to X and X redraws the screen properly and > restores its colormap. I don't know if happened with earlier fbdev versions for you, but one possibility is that X reconfigures the display base, and possibly more bits of the card's internal memory map. Either fbdev should restore that, or adapt to what X set. On R128's and radeon's, this is things like DISPLAY_BASE_ADDR. > The patch below also takes out the CONFIG_NVRAM stuff since it doesn't > work and I don't believe anyone has ever used it. Yup, it's some wacky old pmac stuff that should be killed. > I have also tried aty128fb with some local patches to get it to > compile for my G4 powerbook. It also doesn't draw the penguin, and it > oopses when X starts, for some reason. Hrm... I'll have to test radeonfb... It worked yesteday in console (I don't remember about the penguin) but I didn't try X. |
|
From: Paul M. <pa...@sa...> - 2002-12-10 22:40:24
|
When I look at atyfb_check_var or aty128fb_check_var, I see that they will alter the contents of *info->par. Isn't this a bad thing? My understanding was that after calling check_var, you don't necessarily call set_par next (particularly if check_var returned an error). Also I notice that atyfb_set_par and aty128fb_set_par don't look at info->var, they simply set the hardware state based on the contents of *info->par. Looking at skeletonfb.c, it seems that this is the wrong behaviour. I had fixed the aty128fb.c driver in the linuxppc-2.5 tree. James, if you let me know whether the current behaviour is wrong or not, I'll fix them and send you the patch. Paul. |
|
From: Paul M. <pa...@sa...> - 2002-12-10 22:31:29
|
I tried 2.5.51 on my G3 powerbook (laptop), which has a Rage LT Pro
video chip (ID 0x4c49 or LI). With the patch below, atyfb compiles
and seems to mostly work. However, I didn't see any penguin on boot.
Instead the top inch or so of the screen was just black.
X seems to be running just fine. I have 'Option "UseFBDev"' in my
/etc/X11/XF86Config-4. What doesn't work is changing VTs from X to a
text console. If I press ctrl-alt-F1, for instance, the colormap
changes but I don't see anything get redrawn. The screen looks just
like what I had in X but with the altered colormap. If I then press
alt-F7, it switches back to X and X redraws the screen properly and
restores its colormap.
The other worrying thing is that on two occasions now the machine has
oopsed in free_block(), called from reap_timer_fnc(), because it has
dereferenced a bogus pointer value. When I look at the memory that it
read the pointer from, it looks like a console screen buffer, that is,
the bytes are alternately 0x07 and ascii characters that look like a
login prompt. This happened when waking the machine up from sleep and
when exiting X. It sounds to me like you are freeing a console screen
buffer and then continuing to use it.
The patch below also takes out the CONFIG_NVRAM stuff since it doesn't
work and I don't believe anyone has ever used it.
I have also tried aty128fb with some local patches to get it to
compile for my G4 powerbook. It also doesn't draw the penguin, and it
oopses when X starts, for some reason.
Regards,
Paul.
diff -urN linux-2.5/drivers/video/aty/atyfb_base.c pmac-2.5/drivers/video/aty/atyfb_base.c
--- linux-2.5/drivers/video/aty/atyfb_base.c 2002-12-10 15:29:52.000000000 +1100
+++ pmac-2.5/drivers/video/aty/atyfb_base.c 2002-12-11 09:16:11.000000000 +1100
@@ -70,7 +70,7 @@
#ifdef __powerpc__
#include <asm/prom.h>
-#include <video/macmodes.h>
+#include "../macmodes.h" /* XXX relative include, yuck */
#endif
#ifdef __sparc__
#include <asm/pbm.h>
@@ -84,9 +84,6 @@
#ifdef CONFIG_BOOTX_TEXT
#include <asm/btext.h>
#endif
-#ifdef CONFIG_NVRAM
-#include <linux/nvram.h>
-#endif
#ifdef CONFIG_PMAC_BACKLIGHT
#include <asm/backlight.h>
#endif
@@ -226,14 +223,9 @@
#endif
#ifdef CONFIG_PPC
-#ifdef CONFIG_NVRAM_NOT_DEFINED
-static int default_vmode __initdata = VMODE_NVRAM;
-static int default_cmode __initdata = CMODE_NVRAM;
-#else
static int default_vmode __initdata = VMODE_CHOOSE;
static int default_cmode __initdata = CMODE_CHOOSE;
#endif
-#endif
#ifdef CONFIG_ATARI
static unsigned int mach64_count __initdata = 0;
@@ -1412,16 +1404,16 @@
static int aty_sleep_notify(struct pmu_sleep_notifier *self, int when)
{
struct fb_info *info;
- struct atyfb_par *par = (struct atyfb_par *) info->fb.par;
+ struct atyfb_par *par;
int result;
result = PBOOK_SLEEP_OK;
for (info = first_display; info != NULL; info = par->next) {
- struct fb_fix_screeninfo fix;
int nb;
- nb = fb_display[fg_console].var.yres * info->fix.line_length;
+ par = (struct atyfb_par *) info->par;
+ nb = info->var.yres * info->fix.line_length;
switch (when) {
case PBOOK_SLEEP_REQUEST:
@@ -1439,7 +1431,7 @@
if (par->blitter_may_be_busy)
wait_for_idle(par);
/* Stop accel engine (stop bus mastering) */
- if (par->accel_flags & FB_ACCELF_TEXT)
+ if (info->var.accel_flags & FB_ACCELF_TEXT)
aty_reset_engine(par);
/* Backup fb content */
@@ -1844,14 +1836,6 @@
(&var, info, mode_option, 8))
var = default_var;
} else {
-#ifdef CONFIG_NVRAM
- if (default_vmode == VMODE_NVRAM) {
- default_vmode = nvram_read_byte(NV_VMODE);
- if (default_vmode <= 0
- || default_vmode > VMODE_MAX)
- default_vmode = VMODE_CHOOSE;
- }
-#endif
if (default_vmode == VMODE_CHOOSE) {
if (M64_HAS(G3_PB_1024x768))
/* G3 PowerBook with 1024x768 LCD */
@@ -1873,10 +1857,6 @@
if (default_vmode <= 0
|| default_vmode > VMODE_MAX)
default_vmode = VMODE_640_480_60;
-#ifdef CONFIG_NVRAM
- if (default_cmode == CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
-#endif
if (default_cmode < CMODE_8
|| default_cmode > CMODE_32)
default_cmode = CMODE_8;
|
|
From: James S. <jsi...@in...> - 2002-12-10 21:29:34
|
> Should we add a penguin logo for greyscale displays as well? > > Simon Budig already created one a while ago (cfr. > http://home.tvd.be/cr26864/Linux/fbdev/logo.html and > http://www.home.unix-ag.org/simon/kernel-pingu/). Hm. Do we need it? A few drivers fake greyscale by creating a grey scale colormap. We should try it with the default image. If it doesn't work then we can include it. |
|
From: vivens <vi...@be...> - 2002-12-10 21:06:38
|
Well, I mend it like this: I'm trying to build a framebuffer for an embedded ARM platform (which doesn't use any kind of a Lunix distr). I want to use a framebuffer, because some apps need it. For example the ZEN browser I want to implement on this platform. So my question is: What basic functions does a framebuffer normally have, what is need to initialize for these functions? Can I see the framebuffer as the API between the video hardware and any application what uses the video hardware? Whit kind regards, Vincent Ivens -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of James Simmons Sent: dinsdag 10 december 2002 19:32 To: Vincent Ivens Cc: lin...@li... Subject: Re: [Linux-fbdev-devel] (no subject) > New to the list, is this an appropriate place to ask basic question about > framebuffer divices? > > for example: > what are the basic funtions i can expect in a framebuffer? WHat do you mean? Functionality from a userland perspective or from inside the kernel. Which version of the kernel are you looking at? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Linux-fbdev-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: Antonino D. <ad...@po...> - 2002-12-10 19:24:16
|
Hi,
Here's a diff to correct several small things that escaped through the
cracks.
1. The YNOMOVE scrollmode for non-accelerated drivers is just very slow
because of a lot of block moves (leads to slow and jerky scrolling in
vesafb with ypanning enabled). Depending on var->accel_flags, set the
scrollmode to either YREDRAW or YNOMOVE. For drivers with hardware
acceleration, set var->accel_flags to nonzero for max speed.
2. fb_pan_display() always returns an error. User apps will complain.
3. case FBIO_GETCMAP in fb_ioctl does not return immediately. User
apps will complain.
4. vgastate.c is not saving the correct blocks.
5. logo drawing for monochrome displays is just incorrect.(alterations
were done by eyeballing only, no hardware for testing).
The above will only have a very small effect on the general state of
fbdev/fbcon. Patch is against 2.5.51.
Tony
diff -Naur linux-2.5.51/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.51/drivers/video/console/fbcon.c 2002-12-10 21:55:41.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2002-12-10 21:44:46.000000000 +0000
@@ -291,7 +291,10 @@
struct display *display = fb_display + con;
display->can_soft_blank = info->fbops->fb_blank ? 1 : 0;
- display->scrollmode = SCROLL_YNOMOVE;
+ if (info->var.accel_flags)
+ display->scrollmode = SCROLL_YNOMOVE;
+ else
+ display->scrollmode = SCROLL_YREDRAW;
fbcon_changevar(con);
return;
}
@@ -2633,7 +2636,7 @@
default:
for (i = 0; i < (LOGO_W * LOGO_H)/8; i++)
for (j = 0; j < 8; j++)
- logo[i*2] = (linux_logo_bw[i] & (7 - j)) ?
+ logo[i*8+j] = (linux_logo_bw[i] & (7 - j)) ?
((needs_logo == 1) ? 1 : 0) :
((needs_logo == 1) ? 0 : 1);
diff -Naur linux-2.5.51/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.51/drivers/video/fbmem.c 2002-12-10 21:55:15.000000000 +0000
+++ linux/drivers/video/fbmem.c 2002-12-10 21:47:22.000000000 +0000
@@ -471,11 +471,9 @@
yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
if (info->fbops->fb_pan_display) {
- if ((err = info->fbops->fb_pan_display(var, info)))
- return err;
- else
- return -EINVAL;
- }
+ err = info->fbops->fb_pan_display(var, info);
+ if (err) return err;
+ }
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
if (var->vmode & FB_VMODE_YWRAP)
@@ -571,6 +569,7 @@
if (copy_from_user(&cmap, (void *) arg, sizeof(cmap)))
return -EFAULT;
fb_copy_cmap(&info->cmap, &cmap, 0);
+ return 0;
case FBIOPAN_DISPLAY:
if (copy_from_user(&var, (void *) arg, sizeof(var)))
return -EFAULT;
diff -Naur linux-2.5.51/drivers/video/vgastate.c linux/drivers/video/vgastate.c
--- linux-2.5.51/drivers/video/vgastate.c 2002-12-10 21:55:20.000000000 +0000
+++ linux/drivers/video/vgastate.c 2002-12-10 21:52:31.000000000 +0000
@@ -111,7 +111,7 @@
vga_wgfx(state->vgabase, VGA_GFX_MODE, 0x0);
vga_wgfx(state->vgabase, VGA_GFX_MISC, 0x5);
for (i = 0; i < 8192; i++)
- saved->vga_text[i] = vga_r(fbbase + 2 * 8192, i);
+ saved->vga_text[8192+i] = vga_r(fbbase, i);
}
/* restore regs */
@@ -184,7 +184,7 @@
vga_wgfx(state->vgabase, VGA_GFX_PLANE_READ, 0x3);
vga_wgfx(state->vgabase, VGA_GFX_MODE, 0x0);
vga_wgfx(state->vgabase, VGA_GFX_MISC, 0x5);
- for (i = 0; i < 4 * 8192; i++)
+ for (i = 0; i < state->memsize; i++)
vga_w(fbbase, i, saved->vga_font1[i]);
}
@@ -204,8 +204,7 @@
vga_wgfx(state->vgabase, VGA_GFX_MODE, 0x0);
vga_wgfx(state->vgabase, VGA_GFX_MISC, 0x5);
for (i = 0; i < 8192; i++)
- vga_w(fbbase + 2 * 8192, i,
- saved->vga_text[i]);
+ vga_w(fbbase, i, saved->vga_text[8192+i]);
}
/* unblank screen */
|
|
From: James S. <jsi...@in...> - 2002-12-10 17:40:09
|
> New to the list, is this an appropriate place to ask basic question about > framebuffer divices? > > for example: > what are the basic funtions i can expect in a framebuffer? WHat do you mean? Functionality from a userland perspective or from inside the kernel. Which version of the kernel are you looking at? |
|
From: Geert U. <ge...@li...> - 2002-12-10 13:58:04
|
Should we add a penguin logo for greyscale displays as well? Simon Budig already created one a while ago (cfr. http://home.tvd.be/cr26864/Linux/fbdev/logo.html and http://www.home.unix-ag.org/simon/kernel-pingu/). 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: Sven L. <lu...@dp...> - 2002-12-10 09:12:24
|
On Mon, Dec 09, 2002 at 05:04:27PM -0800, James Simmons wrote: > > > Linus, > > > > any chance you could pull James' updates? He has been sending fbdev updates > > that fix known issues with many drivers for a long time but I can't even > > remember when you merged it the last time. Most fbdev drivers are pretty > > unusable in mainline without his fixes. > > > > James, > > > > could you please provide diffstat output, bk changes -L output and a > > unified diff for review of the actual changes? > > Diff against latest BK 2.5.50 tree is at > > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz Err, could you send also a diff against the 2.5.50 on kernel.org ? Friendly, Sven Luther |
|
From: James S. <jsi...@in...> - 2002-12-10 00:12:53
|
> Linus, > > any chance you could pull James' updates? He has been sending fbdev updates > that fix known issues with many drivers for a long time but I can't even > remember when you merged it the last time. Most fbdev drivers are pretty > unusable in mainline without his fixes. > > James, > > could you please provide diffstat output, bk changes -L output and a > unified diff for review of the actual changes? Diff against latest BK 2.5.50 tree is at http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz bk changes output is: ChangeSet@1.860, 2002-12-09 16:03:32-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.857.1.3, 2002-12-09 15:47:42-08:00, jsi...@ma... New NVIDIA and Radeon cards pci ids. Soon I will add support for these :-) Also a needed fix for fbcon.c. ChangeSet@1.857.1.2, 2002-12-09 08:37:31-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.839.2.2, 2002-12-07 19:24:53-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.831.21.2, 2002-12-07 10:23:33-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.831.10.62, 2002-12-06 16:17:04-08:00, jsimmons@kozmo.(none) Fits the other accel protocols. Fix for blanking. ChangeSet@1.831.17.2, 2002-12-06 12:36:53-08:00, jsimmons@kozmo.(none) VGA text mode handling cleanup. Rusty's janitoral cleanups. ChangeSet@1.831.16.2, 2002-12-06 10:18:16-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.831.15.2, 2002-12-06 07:32:36-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.825.11.4, 2002-12-04 20:37:21-08:00, jsi...@ma... POrted iga fbdev driver to new api. Untested. ChangeSet@1.825.11.3, 2002-12-04 18:09:35-08:00, jsi...@ma... Synced to Linus BK tree. ChangeSet@1.825.11.2, 2002-12-04 17:43:55-08:00, jsi...@ma... Merge ChangeSet@1.797.178.2, 2002-12-04 17:10:40-08:00, jsi...@ma... Supprt for switching hardware from/to vga text mode. ChangeSet@1.797.153.41, 2002-12-02 11:48:57-08:00, jsimmons@kozmo.(none) Ported riva and vga16fb over to new api. Thanks Antonia Daplas!!! More optimizations in fbcon.c ChangeSet@1.797.153.40, 2002-12-02 09:49:02-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.156.3, 2002-12-02 07:38:54-08:00, jsimmons@kozmo.(none) Made fbcon modular. ChangeSet@1.797.156.2, 2002-11-29 09:38:38-08:00, jsimmons@kozmo.(none) Made it modular. ChangeSet@1.797.156.1, 2002-11-27 16:08:48-08:00, jsimmons@kozmo.(none) Merge ChangeSet@1.797.120.7, 2002-11-27 14:40:32-08:00, jsimmons@kozmo.(none) Accel wrapper is now intergarted into fbcon.c. VESA fb fixes ChangeSet@1.797.120.6, 2002-11-27 07:50:13-08:00, jsi...@ma... Diver updates. ChangeSet@1.797.120.5, 2002-11-26 16:04:19-08:00, jsimmons@kozmo.(none) C99 fixes. Framebuffer console fix. ChangeSet@1.797.120.4, 2002-11-26 09:59:16-08:00, jsimmons@kozmo.(none) Moved over fbcon to use the accel api only. This will shrink the code considerably. ChangeSet@1.797.120.3, 2002-11-23 12:45:55-08:00, jsi...@ma... Use the new name of the software cursor function. ChangeSet@1.797.120.2, 2002-11-23 12:36:29-08:00, jsi...@ma... Use remote for now to make sync of trees work. ChangeSet@1.797.126.3, 2002-11-23 11:50:08-08:00, jsi...@ma... Ported Mach64 and NVIDIA driver to final api. A bunch of improvements and bug fixes. ChangeSet@1.797.126.2, 2002-11-23 09:50:57-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.797.120.1, 2002-11-22 14:40:17-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.115.2, 2002-11-22 13:47:35-08:00, jsimmons@kozmo.(none) The software cursor works for any pixel arrangement ChangeSet@1.797.115.1, 2002-11-22 10:02:30-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.100.1, 2002-11-21 07:58:29-08:00, jsi...@ma... Merge bk://fbdev.bkbits.net/fbdev-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.797.78.16, 2002-11-20 15:50:09-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.82.3, 2002-11-19 12:53:44-08:00, jsimmons@kozmo.(none) Nuked font related info in struct display. Almost gone now. ChangeSet@1.797.82.2, 2002-11-19 11:36:22-08:00, jsimmons@kozmo.(none) Creation of default mode. We create and set the hardware once then clone the data each VC. This is much sanier. ChangeSet@1.797.82.1, 2002-11-19 09:49:40-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.76.2, 2002-11-19 07:30:34-08:00, jsi...@ma... Merge bk://fbdev.bkbits.net/fbdev-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.797.67.1, 2002-11-18 10:27:55-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.40.3, 2002-11-18 09:31:34-08:00, jsimmons@kozmo.(none) Start of intergartion of fbcon-accel into the core fbcon code. ChangeSet@1.797.43.3, 2002-11-16 17:36:03-08:00, jsi...@ma... Merge ChangeSet@1.797.43.2, 2002-11-16 17:21:19-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.797.40.2, 2002-11-15 17:37:46-08:00, jsimmons@kozmo.(none) Massive cleanup of struct display. It will be going away. ChangeSet@1.797.22.9, 2002-11-15 14:01:40-08:00, jsimmons@kozmo.(none) Moving over to console_font_op to get ride of struct display. ChangeSet@1.797.22.8, 2002-11-15 09:48:21-08:00, jsimmons@kozmo.(none) Cleaned up the cursor api. Now it uses fb_imaeg which makes sense since a cursor is a image.More code cleanup for fbcon.c. Removal of excess elements passed into functions. ChangeSet@1.797.22.7, 2002-11-15 09:36:23-08:00, jsimmons@kozmo.(none) Merge kozmo.(none):/usr/src/linus-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.22.6, 2002-11-14 16:55:10-08:00, jsimmons@kozmo.(none) Start of hardware rotation. PDA devices have often rotated screens with respect to the keyboard.' ChangeSet@1.797.22.4, 2002-11-14 14:08:32-08:00, jsimmons@kozmo.(none) Major fixes for the software accel functions. We have the penguin back. ChangeSet@1.797.22.3, 2002-11-14 11:16:22-08:00, jsimmons@kozmo.(none) fbgen is gone and now we have cfbcursor.c ChangeSet@1.797.22.2, 2002-11-13 16:13:32-08:00, jsimmons@kozmo.(none) Grabbed the PPC drivers and in the process of porting to the latest api. Can now use driver specific read and write functions ChangeSet@1.797.6.3, 2002-11-12 08:04:25-08:00, jsi...@ma... Simplification of the code. ChangeSet@1.797.11.1, 2002-11-11 11:37:22-08:00, jsimmons@kozmo.(none) Merge bk://fbdev@bkbits.net/fbdev-2.5 into kozmo.(none):/usr/src/fbdev-2.5 ChangeSet@1.797.4.3, 2002-11-10 13:03:09-08:00, jsi...@ma... Fixed the anakin and noemagic framebuffer driver. Made font selection depeneded on framebuffer consoel instead of just framebuffer support. Fixed return to be int for tx3912 framebuffer. ChangeSet@1.797.4.2, 2002-11-09 13:10:43-08:00, jsi...@ma... Auto merged except for parisc Kconfig. I have to sync by hand. ChangeSet@1.786.1.96, 2002-11-08 00:03:44-08:00, jsi...@ma... Several fixes relating to modules. Ported over the vga16fb driver to the new api. ChangeSet@1.786.1.95, 2002-11-07 13:47:46-08:00, jsi...@ma... Moved stuff into drivers/video/console. ChangeSet@1.786.1.94, 2002-11-07 13:33:20-08:00, jsi...@ma... Merge ChangeSet@1.786.1.93, 2002-11-07 09:07:28-08:00, jsi...@ma... Bug fixes!! ChangeSet@1.786.1.92, 2002-11-02 18:04:34-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.162.3, 2002-11-01 17:07:16-08:00, jsi...@ma... Neomagic and HGA updates. MAde the software accel code modular. So code cleanup in fbcon. More to go. ChangeSet@1.786.162.2, 2002-11-01 15:37:07-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.133.3, 2002-10-31 12:06:21-08:00, jsi...@ma... Moved all console configuration out of arch directories into drivers/video/console. Allow resize of a single VC via the tty layer. Nuked GET_FB_IDX. ChangeSet@1.786.133.2, 2002-10-30 20:57:19-08:00, jsi...@ma... Ug. Synced up. ChangeSet@1.786.125.2, 2002-10-30 09:57:16-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.115.2, 2002-10-29 20:29:15-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.107.4, 2002-10-29 14:42:41-08:00, jsi...@ma... Moved AGP and DRM code back to drivers/char until a proper solution is done for handling AGP/DMA based framebuffer devices. ChangeSet@1.786.107.3, 2002-10-29 12:06:00-08:00, jsi...@ma... Updates to STI framebuffer and STI console. Cleanup of include/video and a few minor fixes. ChangeSet@1.786.107.2, 2002-10-29 11:18:47-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.52.5, 2002-10-28 16:08:25-08:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.52.4, 2002-10-24 10:59:49-07:00, jsi...@ma... Moved over fbcon related files to the video/console directory. I also updated a few more drivers to the new api. ChangeSet@1.786.52.3, 2002-10-21 10:28:49-07:00, jsi...@ma... Cleaned up the console blank handling. ChangeSet@1.786.52.2, 2002-10-21 10:15:32-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.25.4, 2002-10-18 13:48:05-07:00, jsi...@ma... Added a cursor api. ChangeSet@1.786.25.3, 2002-10-18 11:48:32-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.786.9.3, 2002-10-16 21:27:33-07:00, jsi...@ma... Synced up to Linus tree. Fixed the conflict. ChangeSet@1.786.9.2, 2002-10-16 21:12:20-07:00, jsi...@ma... Synced up. ChangeSet@1.786.4.3, 2002-10-16 21:06:36-07:00, jsi...@ma... The last of the console code inside the frmaebuffer layer. I also moved all the graphics related code into the drivers/video directory. ChangeSet@1.786.4.2, 2002-10-16 11:18:08-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.781.1.13, 2002-10-16 11:08:50-07:00, jsi...@ma... Oops. Forgot to include sis_accel.o ChangeSet@1.781.1.12, 2002-10-16 10:46:14-07:00, jsi...@ma... Cleaned up and moved all the graphics related code inf drivers/video and move the console display related stuff into lower directory called console. ChangeSet@1.781.1.11, 2002-10-14 09:38:39-07:00, jsi...@ma... Replace with Russell's driver. ChangeSet@1.781.1.10, 2002-10-14 09:34:28-07:00, jsi...@ma... Uses Russell's latest driver. ChangeSet@1.781.5.11, 2002-10-12 12:53:47-07:00, jsi...@ma... Removed last console and old api related things. Removed experimental flags. ChangeSet@1.781.5.10, 2002-10-12 11:16:44-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.738.14.2, 2002-10-11 11:49:40-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.714.13.2, 2002-10-09 13:54:17-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.573.118.15, 2002-10-09 08:34:30-07:00, jsi...@ma... Removed currcon and other console related code. Very little is now left. ChangeSet@1.573.118.14, 2002-10-08 11:22:38-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.497.104.5, 2002-09-12 15:27:08-07:00, jsi...@ma... Cleanup to match closely Linus tree. ChangeSet@1.497.104.4, 2002-09-12 15:16:51-07:00, jsi...@ma... Auto merged ChangeSet@1.497.47.2, 2002-09-12 12:06:08-07:00, jsi...@ma... Remove old fbcon-cfb files. ChangeSet@1.497.33.1, 2002-08-28 22:56:02-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.497.27.1, 2002-08-27 22:05:49-07:00, jsi...@ma... Merge http://fbdev.bkbits.net/fbdev-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.485.4.15, 2002-08-27 12:29:03-07:00, jsi...@ma... Added support for logo displaying for new api. Now new code supports 24 bpp. ChangeSet@1.485.4.14, 2002-08-27 12:14:59-07:00, jsi...@ma... More fbdev api cleanups. Removed modename from struct fb_info. Incorporated Paul's fixes. The cfb stuff is finally going away. ChangeSet@1.485.4.12, 2002-08-20 22:15:23-07:00, jsi...@ma... Further api porting. Almost done. Here we eliminate get[set]_cmap from struct fb_ops. Also set_disp has ben moved into fbcon.c instead of the drivers. ChangeSet@1.485.11.1, 2002-08-19 08:30:12-07:00, jsi...@ma... Merge maxwell.earthlink.net:/usr/src/linus-2.5 into maxwell.earthlink.net:/usr/src/fbdev-2.5 ChangeSet@1.456.25.48, 2002-08-15 21:23:55-07:00, jsi...@ma... Ooops. Fix from Paul Mackerras ChangeSet@1.456.25.47, 2002-08-15 21:05:45-07:00, jsi...@ma... Synced up. ChangeSet@1.456.25.46, 2002-08-14 21:27:21-07:00, jsi...@ma... Petr fix to make old api driver to work. Diffstat output is: CREDITS | 10 Documentation/DocBook/kernel-api.tmpl | 4 Documentation/fb/README-sstfb.txt | 173 Documentation/fb/internals.txt | 5 Documentation/fb/sstfb.txt | 174 MAINTAINERS | 7 arch/alpha/Kconfig | 31 arch/arm/Kconfig | 21 arch/i386/Kconfig | 55 arch/i386/vmlinux.lds.s | 114 arch/ia64/Kconfig | 25 arch/m68k/Kconfig | 7 arch/m68knommu/Kconfig | 35 arch/mips/Kconfig | 62 arch/mips64/Kconfig | 23 arch/parisc/Kconfig | 30 arch/ppc/Kconfig | 22 arch/ppc64/Kconfig | 7 arch/sh/Kconfig | 55 arch/sparc/Kconfig | 16 arch/sparc64/Kconfig | 11 arch/v850/Kconfig | 35 arch/x86_64/Kconfig | 55 drivers/Makefile | 3 drivers/char/Makefile | 2 drivers/char/consolemap.c | 5 drivers/char/keyboard.c | 1 drivers/char/mem.c | 12 drivers/char/selection.c | 1 drivers/char/toshiba.c | 2 drivers/char/tty_io.c | 7 drivers/char/vc_screen.c | 1 drivers/char/vt.c | 200 - drivers/char/vt_ioctl.c | 58 drivers/video/68328fb.c | 967 +---- drivers/video/Kconfig | 411 -- drivers/video/Makefile | 58 drivers/video/S3triofb.c | 2 drivers/video/amifb.c | 2 drivers/video/anakinfb.c | 62 drivers/video/atafb.c | 2 drivers/video/aty/atyfb.h | 18 drivers/video/aty/atyfb_base.c | 99 drivers/video/aty/mach64_ct.c | 2 drivers/video/aty/mach64_cursor.c | 157 drivers/video/aty/mach64_gx.c | 2 drivers/video/aty128fb.c | 3257 +++++++---------- drivers/video/cfbcopyarea.c | 511 +- drivers/video/cfbfillrect.c | 536 ++ drivers/video/cfbimgblt.c | 360 + drivers/video/chipsfb.c | 2 drivers/video/clps711xfb.c | 16 drivers/video/console/Kconfig | 221 + drivers/video/console/Makefile | 61 drivers/video/console/dummycon.c | 73 drivers/video/console/fbcon-sti.c | 289 + drivers/video/console/fbcon.c | 2846 +++++++++++++++ drivers/video/console/fbcon.h | 142 drivers/video/console/font.h | 53 drivers/video/console/font_6x11.c | 3351 +++++++++++++++++ drivers/video/console/font_8x16.c | 4631 ++++++++++++++++++++++++ drivers/video/console/font_8x8.c | 2583 +++++++++++++ drivers/video/console/font_acorn_8x8.c | 277 + drivers/video/console/font_mini_4x6.c | 2158 +++++++++++ drivers/video/console/font_pearl_8x8.c | 2587 +++++++++++++ drivers/video/console/font_sun12x22.c | 6220 +++++++++++++++++++++++++++++++++ drivers/video/console/font_sun8x16.c | 275 + drivers/video/console/fonts.c | 142 drivers/video/console/mdacon.c | 631 +++ drivers/video/console/newport_con.c | 745 +++ drivers/video/console/prom.uni | 11 drivers/video/console/promcon.c | 605 +++ drivers/video/console/sti.h | 289 + drivers/video/console/sticon.c | 214 + drivers/video/console/sticore.c | 601 +++ drivers/video/console/vgacon.c | 1066 +++++ drivers/video/controlfb.c | 499 -- drivers/video/cyberfb.c | 2 drivers/video/dnfb.c | 18 drivers/video/dummycon.c | 74 drivers/video/epson1355fb.c | 2 drivers/video/fbcmap.c | 92 drivers/video/fbcon-accel.c | 188 drivers/video/fbcon-accel.h | 34 drivers/video/fbcon-afb.c | 448 -- drivers/video/fbcon-cfb16.c | 319 - drivers/video/fbcon-cfb2.c | 225 - drivers/video/fbcon-cfb24.c | 333 - drivers/video/fbcon-cfb32.c | 305 - drivers/video/fbcon-cfb4.c | 229 - drivers/video/fbcon-cfb8.c | 294 - drivers/video/fbcon-hga.c | 253 - drivers/video/fbcon-ilbm.c | 296 - drivers/video/fbcon-iplan2p2.c | 476 -- drivers/video/fbcon-iplan2p4.c | 497 -- drivers/video/fbcon-iplan2p8.c | 534 -- drivers/video/fbcon-mfb.c | 217 - drivers/video/fbcon-sti.c | 337 - drivers/video/fbcon-vga-planes.c | 387 -- drivers/video/fbcon.c | 2508 ------------- drivers/video/fbgen.c | 286 - drivers/video/fbmem.c | 252 - drivers/video/fm2fb.c | 17 drivers/video/font_6x11.c | 3351 ----------------- drivers/video/font_8x16.c | 4631 ------------------------ drivers/video/font_8x8.c | 2583 ------------- drivers/video/font_acorn_8x8.c | 277 - drivers/video/font_mini_4x6.c | 2158 ----------- drivers/video/font_pearl_8x8.c | 2587 ------------- drivers/video/font_sun12x22.c | 6220 --------------------------------- drivers/video/font_sun8x16.c | 275 - drivers/video/fonts.c | 135 drivers/video/g364fb.c | 74 drivers/video/hgafb.c | 424 -- drivers/video/hitfb.c | 17 drivers/video/hpfb.c | 16 drivers/video/iga.h | 29 drivers/video/igafb.c | 581 +-- drivers/video/imsttfb.c | 41 drivers/video/macfb.c | 22 drivers/video/macmodes.c | 3 drivers/video/macmodes.h | 70 drivers/video/matrox/i2c-matroxfb.c | 2 drivers/video/matrox/matroxfb_base.c | 4 drivers/video/matrox/matroxfb_crtc2.c | 4 drivers/video/maxinefb.c | 48 drivers/video/mdacon.c | 632 --- drivers/video/modedb.c | 7 drivers/video/neofb.c | 389 +- drivers/video/newport_con.c | 746 --- drivers/video/offb.c | 23 drivers/video/platinumfb.c | 451 -- drivers/video/pm2fb.c | 7 drivers/video/pm3fb.c | 7 drivers/video/pmag-ba-fb.c | 59 drivers/video/pmagb-b-fb.c | 53 drivers/video/prom.uni | 11 drivers/video/promcon.c | 606 --- drivers/video/pvr2fb.c | 4 drivers/video/q40fb.c | 16 drivers/video/radeon.h | 766 ---- drivers/video/radeonfb.c | 3734 +++++++++++-------- drivers/video/retz3fb.c | 2 drivers/video/riva/Makefile | 2 drivers/video/riva/accel.c | 427 -- drivers/video/riva/fbdev.c | 2251 +++++------ drivers/video/riva/fbdev.c.new | 2036 ++++++++++ drivers/video/riva/nv_driver.c | 212 + drivers/video/riva/nv_type.h | 58 drivers/video/riva/riva_hw.c.new | 2205 +++++++++++ drivers/video/riva/riva_hw.h | 1 drivers/video/riva/riva_hw.h.new | 547 ++ drivers/video/riva/riva_tbl.h.new | 1008 +++++ drivers/video/riva/rivafb.h | 52 drivers/video/riva/rivafb.h.new | 54 drivers/video/sa1100fb.c | 2 drivers/video/sbusfb.c | 2 drivers/video/sgivwfb.c | 62 drivers/video/sis/Makefile | 2 drivers/video/sis/sis_accel.c | 495 ++ drivers/video/sis/sis_main.c | 2 drivers/video/skeletonfb.c | 28 drivers/video/softcursor.c | 62 drivers/video/sstfb.c | 2 drivers/video/sti-bmode.h | 287 - drivers/video/sti.h | 289 - drivers/video/sticon-bmode.c | 895 ---- drivers/video/sticon.c | 215 - drivers/video/sticore.c | 601 --- drivers/video/sticore.h | 407 ++ drivers/video/stifb.c | 1403 ++++++- drivers/video/sun3fb.c | 2 drivers/video/tdfxfb.c | 531 +- drivers/video/tgafb.c | 7 drivers/video/tridentfb.c | 2 drivers/video/tx3912fb.c | 19 drivers/video/valkyriefb.c | 27 drivers/video/vesafb.c | 24 drivers/video/vfb.c | 36 drivers/video/vga.h | 457 -- drivers/video/vga16fb.c | 1403 +++++-- drivers/video/vgacon.c | 1055 ----- drivers/video/vgastate.c | 503 ++ drivers/video/virgefb.c | 2 include/linux/console.h | 1 include/linux/console_struct.h | 1 include/linux/fb.h | 207 - include/linux/pci_ids.h | 18 include/linux/radeonfb.h | 15 include/linux/sisfb.h | 58 include/linux/vt_kern.h | 8 include/video/fbcon-afb.h | 32 include/video/fbcon-cfb16.h | 34 include/video/fbcon-cfb2.h | 32 include/video/fbcon-cfb24.h | 34 include/video/fbcon-cfb32.h | 34 include/video/fbcon-cfb4.h | 32 include/video/fbcon-cfb8.h | 34 include/video/fbcon-hga.h | 32 include/video/fbcon-ilbm.h | 32 include/video/fbcon-iplan2p2.h | 32 include/video/fbcon-iplan2p4.h | 32 include/video/fbcon-iplan2p8.h | 32 include/video/fbcon-mac.h | 32 include/video/fbcon-mfb.h | 32 include/video/fbcon-vga-planes.h | 37 include/video/fbcon-vga.h | 32 include/video/fbcon.h | 795 ---- include/video/font.h | 53 include/video/iga.h | 24 include/video/macmodes.h | 70 include/video/neomagic.h | 1 include/video/radeon.h | 766 ++++ include/video/vga.h | 480 ++ kernel/printk.c | 1 215 files changed, 49572 insertions(+), 49117 deletions(-) |
|
From: Christoph H. <hc...@in...> - 2002-12-09 23:38:58
|
On Mon, Dec 09, 2002 at 04:23:08PM -0800, James Simmons wrote: > > Hi Linus!!! > > Here are the fbdev updates people have so been waiting for. Several > drivers have been ported. Many fixes have been implemented and many nice > features have been added as well. Please pull the changes. They have been > tested by people on this list. Thank you. > > bk://fbdev.bkbits.net/fbdev-2.5 Linus, any chance you could pull James' updates? He has been sending fbdev updates that fix known issues with many drivers for a long time but I can't even remember when you merged it the last time. Most fbdev drivers are pretty unusable in mainline without his fixes. James, could you please provide diffstat output, bk changes -L output and a unified diff for review of the actual changes? |
|
From: James S. <jsi...@in...> - 2002-12-09 23:31:28
|
Hi Linus!!! Here are the fbdev updates people have so been waiting for. Several drivers have been ported. Many fixes have been implemented and many nice features have been added as well. Please pull the changes. They have been tested by people on this list. Thank you. bk://fbdev.bkbits.net/fbdev-2.5 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: Jakub B. <qb...@pl...> - 2002-12-09 22:29:20
|
(note that I'm not subscriber, so please Cc answers to me) Is this list proper place for tdfxfb-related things, or should I post to some other address (linux-kernel?)? I don't see tdfxfb in MAINTAINERS file. 1. hardware cursor (seems to be Voodoo4, maybe Voodoo5 too, specific). On my Voodoo4 4500 I got some (mostly white) junk in bottom 48 (of 64) lines of hardware cursor. After setting hardware cursor base 1 page lower (alternatively speaking, rounding it to even page boundary), cursor is displayed correctly. 2. 16/24/32bpp modes should be defined as TRUECOLOR, not DIRECTCOLOR. It's because Voodoo (or at least tdfxfb driver) doesn't support colour mapping in high- and true-colour modes. This seems to be already fixed in Linux 2.5 tree. It caused displaying Tux logo in wrong colours on 16/24/32bpp tdfxfb. 3. (partial) double-scan modes support. Double-scan modes were silently not supported (flag was set only in internal data structure, but not in chipset); with my patch, it's possible to set such mode (but without hardware cursor - because it's handled in normal Y coordinate, not doubled). 4. interlaced modes support. As far as I could find - Voodoo Banshee doesn't support interlace, but Voodoo3 (at least some models) and higher do. With patch, it works on my Voodoo4 4500 (refresh rate seems to be fixed at 50Hz (for TV Out, which I don't have?), but it's still useful for displaying some high resolution picture for a while). Attached patch was made againt Linux 2.4.20, and requires some changes for 2.5 tree (BTW, it seems that hardware cursor support is gone in tdfxfb for 2.5?). -- Jakub Bogusz http://www.cs.net.pl/~qboosh/ PLD Linux http://www.pld.org.pl/ |
|
From: Geert U. <ge...@li...> - 2002-12-08 11:49:17
|
On Thu, 28 Nov 2002, Geert Uytterhoeven wrote: > On 25 Nov 2002, Johan Bolmsjo wrote: > > For what it's worth, the interleaved modes on atari works like this: > > > > The bitplanes are interleaved on 16 bit big-endian word basis so if you > > have two bitplanes, bit 0 of the first 16 pixels would be in the first > > 16 bit word in the display memory, bit 1 of the first 16 pixels would be > > in the second word. With bit 0 I mean as masked out by & 0x0001 in C, > > and bit 1 as masked out by 0x0002. > > Thanks! This is exactly the kind of information I needed! > > I added simple unoptimized support for Atari interleaved bitplanes to fbtest. > When I know I got the basics right, I can start writing optimized drawing > routines. > > Anyone who cares to give it a try? Just check out CVS module `fbtest' from > http://sourceforge.net/cvs/?group_id=908, type `make' and run `fbtest' for all > available color depths (use fbset first), and tell me whether it works. > > If no one is left with an Atari with Linux/m68k installed, I can create a > ramdisk containing fbset and fbtest, so you just need ataboot and a kernel to > test it. I put the ramdisk at http://home.tvd.be/cr26864/Linux/m68k/ramdisk-fbtest-m68k.gz Just boot it with whatever kernel (incl. atafb, of course) you have, and run `fbtest' for all available color depths. You can change the color depth with `fbset -depth <depth>'. Note that it will be slow, since so far I implemented single pixel drawing only. Thanks for testing! Gr{oetje,eeting}s, Geert P.S. Sorry that it took that long, but my Amiga 4000 needed urgent surgery due to a leaking NiCd battery that started to corrode the mainboard. Fortunately I managed to replace it in time by a new NiMH part. -- 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: Clifford T. M. <ct...@ar...> - 2002-12-08 08:13:03
|
I have a Micron Millennium Transport laptop with Cirrus CL-GD7548
based video. It works fine in 16bpp using the Cirrus XFree86 4.2.0
driver. /dev/fb works fine at 8bpp, but didn't work at 16bpp. I
looked at the two drivers and made clgenfb.c do a few things the
XFree86 driver was doing and now 16bpp appears to work fine on that
laptop.
I don't subscribe to linux-fbdev-devel, but do read lkml via a
leisurely Usenet feed.
--Cliff Matthews After some people managed to scale the wall,
ct...@ar... there was a ban on the sale of rope and twine.
diff -Naur linux-2.4.20/drivers/video/clgenfb.c linux-2.4.20-clpatch/drivers/video/clgenfb.c
--- linux-2.4.20/drivers/video/clgenfb.c 2002-11-28 16:53:15.000000000 -0700
+++ linux-2.4.20-clpatch/drivers/video/clgenfb.c 2002-12-07 23:34:54.000000000 -0700
@@ -15,6 +15,9 @@
* Lars Hecking:
* Amiga updates and testing.
*
+ * Cliff Matthews <ct...@ar...>:
+ * 16bpp fix for CL-GD7548 (uses info from XFree86 4.2.0 source)
+ *
* Original clgenfb author: Frank Neumann
*
* Based on retz3fb.c and clgen.c:
@@ -403,6 +406,9 @@
#ifdef CONFIG_PCI
struct pci_dev *pdev;
+#define IS_7548(x) ((x)->pdev->device == PCI_DEVICE_ID_CIRRUS_7548)
+#else
+#define IS_7548(x) (FALSE)
#endif
};
@@ -970,7 +976,10 @@
DPRINTK ("desired pixclock: %ld kHz\n", freq);
- maxclock = clgen_board_info[fb_info->btype].maxclock;
+ if (IS_7548(fb_info))
+ maxclock = 80100;
+ else
+ maxclock = clgen_board_info[fb_info->btype].maxclock;
_par->multiplexing = 0;
/* If the frequency is greater than we can support, we might be able
@@ -1478,10 +1487,17 @@
case BT_ALPINE:
DPRINTK (" (for GD543x)\n");
- if (_par->HorizRes >= 1024)
- vga_wseq (fb_info->regs, CL_SEQR7, 0xa7);
- else
- vga_wseq (fb_info->regs, CL_SEQR7, 0xa3);
+ if (IS_7548(fb_info)) {
+ vga_wseq (fb_info->regs, CL_SEQR7,
+ (vga_rseq (fb_info->regs, CL_SEQR7) & 0xE0)
+ | 0x17);
+ WHDR (fb_info, 0xC1);
+ } else {
+ if (_par->HorizRes >= 1024)
+ vga_wseq (fb_info->regs, CL_SEQR7, 0xa7);
+ else
+ vga_wseq (fb_info->regs, CL_SEQR7, 0xa3);
+ }
clgen_set_mclk (fb_info, _par->mclk, _par->divMCLK);
break;
@@ -1594,6 +1610,11 @@
_par->var.bits_per_pixel);
}
+ if (IS_7548(fb_info)) {
+ vga_wseq (fb_info->regs, CL_SEQR2D,
+ vga_rseq (fb_info->regs, CL_SEQR2D) | 0xC0);
+ }
+
vga_wcrt (fb_info->regs, VGA_CRTC_OFFSET, offset & 0xff);
tmp = 0x22;
if (offset & 0x100)
diff -Naur linux-2.4.20/drivers/video/clgenfb.h linux-2.4.20-clpatch/drivers/video/clgenfb.h
--- linux-2.4.20/drivers/video/clgenfb.h 2000-01-06 11:23:46.000000000 -0700
+++ linux-2.4.20-clpatch/drivers/video/clgenfb.h 2002-12-07 20:50:43.000000000 -0700
@@ -60,6 +60,7 @@
#define CL_SEQR1D 0x1d /* VCLK2 Denominator and Post-Scalar Value */
#define CL_SEQR1E 0x1e /* VCLK3 Denominator and Post-Scalar Value */
#define CL_SEQR1F 0x1f /* BIOS ROM write enable and MCLK Select */
+#define CL_SEQR2D 0x2d /* unknown, snagged from XFree86 4.2.0 */
/*** CRT Controller Registers ***/
#define CL_CRT22 0x22 /* Graphics Data Latches ReadBack */
|
|
From: James S. <jsi...@in...> - 2002-12-06 21:26:09
|
Hi!!! After much work and many fixes the final api for the framebuffer layer is complete and alot of new functionality has been added. Several drivers have been ported. Still several more to go. Could you grab the latest changes from bk://fbdev.bkbits.net/fbdev-2.5 Please sync it up to your latest tree. Thank you. |
|
From: James S. <jsi...@in...> - 2002-12-06 21:23:04
|
> > Hi! > > > > I have a new patch avaiable. It is against 2.5.50. The patch is at > > Any chance you could sync with linus again? fb in mainline is pretty > rotten.. I think the time has come. Alot of improvmenents have happened :-) The final api for the low level drivers is done. Any further changes will be in fbmem.c and fbcon. I just synced up the latest work. |
|
From: Christoph H. <hc...@in...> - 2002-12-06 19:51:15
|
On Mon, Dec 02, 2002 at 09:07:33PM +0000, James Simmons wrote: > > Hi! > > I have a new patch avaiable. It is against 2.5.50. The patch is at Any chance you could sync with linus again? fb in mainline is pretty rotten.. |
|
From: Antonino D. <ad...@po...> - 2002-12-06 12:35:05
|
On Fri, 2002-12-06 at 05:53, James Simmons wrote: > > > > Only the structure definition of fb_vgastate is in fb.h. For drivers > > without a vga core, they'll just won't link to it and it won't be > > compiled. Plus, vga.h is not a common header (not located in > > include/asm or include/linux) and it contains a lot of declarations and > > definitions which are irrelevant to most drivers or are already > > duplicated. This will be messier, I think. > > I like to move vga.h to include/video. And yes I like to clean it up. The > reason is I like to implement the function in vga.h and some in vgastate > into vgacon.c. It would be nice if vgacon could support different hardware > states per VC instead of changing every virtual console for everything. > The other dream is I like to see vgacon become firmware independent. > OK. Tony |