* Radeon Framebuffer Driver in 2.6.3?
@ 2004-02-27 6:27 arief#
2004-02-27 7:04 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 14+ messages in thread
From: arief# @ 2004-02-27 6:27 UTC (permalink / raw)
To: linux-kernel
Dear all,
Before, please cc me the answer, as I'm not on the list right now.
In 2.6.3 (including -mmX patches), radeon framebuffer seems to having
problems. Everytime I do clear screen, it only 'half cleared'. I still
can see the mark of the previous texts in shaded mode. And it does not
do deletion well, too.
Anybody else having the same problem?
I like to see what's the problem, but I don't know framebuffer code (or
any kernel code at all) well. If someone could give me pointer, I could
give it a shot.
My hardware is, IBM Thinkpad T30 with Radeon 7500 card.
2.6.2 and 2.4 does not have this problem.
Regards.
-arief
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 6:27 Radeon Framebuffer Driver in 2.6.3? arief#
@ 2004-02-27 7:04 ` Benjamin Herrenschmidt
2004-02-27 10:06 ` arief#
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Benjamin Herrenschmidt @ 2004-02-27 7:04 UTC (permalink / raw)
To: arief#; +Cc: Linux Kernel list
On Fri, 2004-02-27 at 17:27, arief# wrote:
> Dear all,
>
>
> Before, please cc me the answer, as I'm not on the list right now.
>
> In 2.6.3 (including -mmX patches), radeon framebuffer seems to having
> problems. Everytime I do clear screen, it only 'half cleared'. I still
> can see the mark of the previous texts in shaded mode. And it does not
> do deletion well, too.
>
> Anybody else having the same problem?
If it happens only after switching back from XFree, then it's a known
problem. I have implemented a fix locally but got sidetracked before I
could test it properly.
Can you test the patch below ? :
===== drivers/char/vt.c 1.61 vs edited =====
--- 1.61/drivers/char/vt.c Thu Feb 19 14:43:03 2004
+++ edited/drivers/char/vt.c Fri Feb 27 17:27:09 2004
@@ -2743,12 +2743,12 @@
* Called only if powerdown features are allowed.
*/
switch (vesa_blank_mode) {
- case VESA_NO_BLANKING:
- c->vc_sw->con_blank(c, VESA_VSYNC_SUSPEND+1);
+ case VESA_NO_BLANKING:
+ c->vc_sw->con_blank(c, VESA_VSYNC_SUSPEND+1, 0);
break;
- case VESA_VSYNC_SUSPEND:
- case VESA_HSYNC_SUSPEND:
- c->vc_sw->con_blank(c, VESA_POWERDOWN+1);
+ case VESA_VSYNC_SUSPEND:
+ case VESA_HSYNC_SUSPEND:
+ c->vc_sw->con_blank(c, VESA_POWERDOWN+1, 0);
break;
}
}
@@ -2776,7 +2776,7 @@
if (entering_gfx) {
hide_cursor(currcons);
save_screen(currcons);
- sw->con_blank(vc_cons[currcons].d, -1);
+ sw->con_blank(vc_cons[currcons].d, -1, 1);
console_blanked = fg_console + 1;
set_origin(currcons);
return;
@@ -2794,7 +2794,7 @@
save_screen(currcons);
/* In case we need to reset origin, blanking hook returns 1 */
- i = sw->con_blank(vc_cons[currcons].d, 1);
+ i = sw->con_blank(vc_cons[currcons].d, 1, 0);
console_blanked = fg_console + 1;
if (i)
set_origin(currcons);
@@ -2808,14 +2808,14 @@
}
if (vesa_blank_mode)
- sw->con_blank(vc_cons[currcons].d, vesa_blank_mode + 1);
+ sw->con_blank(vc_cons[currcons].d, vesa_blank_mode + 1, 0);
}
/*
* Called by timer as well as from vt_console_driver
*/
-void unblank_screen(void)
+void do_unblank_screen(int leaving_gfx)
{
int currcons;
@@ -2839,13 +2839,24 @@
}
console_blanked = 0;
- if (sw->con_blank(vc_cons[currcons].d, 0))
+ if (sw->con_blank(vc_cons[currcons].d, 0, leaving_gfx))
/* Low-level driver cannot restore -> do it ourselves */
update_screen(fg_console);
if (console_blank_hook)
console_blank_hook(0);
set_palette(currcons);
set_cursor(fg_console);
+}
+
+/*
+ * This is called by the outside world to cause a forced unblank, mostly for
+ * oopses. Currently, I just call do_unblank_screen(0), but we could eventually
+ * call it with 1 as an argument and so force a mode restore... that may kill
+ * X or at least garbage the screen but would also make the Oops visible...
+ */
+void unblank_screen(void)
+{
+ do_unblank_screen(0);
}
/*
===== drivers/char/vt_ioctl.c 1.34 vs edited =====
--- 1.34/drivers/char/vt_ioctl.c Wed Feb 25 21:31:13 2004
+++ edited/drivers/char/vt_ioctl.c Fri Feb 27 17:27:21 2004
@@ -497,7 +497,7 @@
*/
acquire_console_sem();
if (arg == KD_TEXT)
- unblank_screen();
+ do_unblank_screen(1);
else
do_blank_screen(1);
release_console_sem();
@@ -1103,7 +1103,7 @@
if (old_vc_mode != vt_cons[new_console]->vc_mode)
{
if (vt_cons[new_console]->vc_mode == KD_TEXT)
- unblank_screen();
+ do_unblank_screen(1);
else
do_blank_screen(1);
}
@@ -1138,7 +1138,7 @@
if (old_vc_mode != vt_cons[new_console]->vc_mode)
{
if (vt_cons[new_console]->vc_mode == KD_TEXT)
- unblank_screen();
+ do_unblank_screen(1);
else
do_blank_screen(1);
}
===== drivers/video/fbmem.c 1.90 vs edited =====
--- 1.90/drivers/video/fbmem.c Mon Feb 16 23:42:15 2004
+++ edited/drivers/video/fbmem.c Fri Feb 27 17:25:21 2004
@@ -943,7 +943,8 @@
{
int err;
- if (memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
+ if ((var->activate & FB_ACTIVATE_FORCE) ||
+ memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
if (!info->fbops->fb_check_var) {
*var = info->var;
return 0;
===== drivers/video/console/fbcon.c 1.109 vs edited =====
--- 1.109/drivers/video/console/fbcon.c Mon Feb 16 05:22:04 2004
+++ edited/drivers/video/console/fbcon.c Fri Feb 27 17:47:24 2004
@@ -159,7 +159,7 @@
static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
int height, int width);
static int fbcon_switch(struct vc_data *vc);
-static int fbcon_blank(struct vc_data *vc, int blank);
+static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
static int fbcon_font_op(struct vc_data *vc, struct console_font_op *op);
static int fbcon_set_palette(struct vc_data *vc, unsigned char *table);
static int fbcon_scrolldelta(struct vc_data *vc, int lines);
@@ -1696,14 +1696,23 @@
return 1;
}
-static int fbcon_blank(struct vc_data *vc, int blank)
+static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
{
unsigned short charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
struct display *p = &fb_display[vc->vc_num];
- if (blank < 0) /* Entering graphics mode */
- return 0;
+ if (mode_switch) {
+ struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
+ struct fb_var_screeninfo var = info->var;
+
+ if (blank) {
+ fbcon_cursor(vc, CM_ERASE);
+ return 0;
+ }
+ var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
+ fb_set_var(info, &var);
+ }
fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
===== drivers/video/console/promcon.c 1.9 vs edited =====
--- 1.9/drivers/video/console/promcon.c Wed Dec 11 14:49:09 2002
+++ edited/drivers/video/console/promcon.c Fri Feb 27 17:24:34 2004
@@ -463,7 +463,7 @@
}
static int
-promcon_blank(struct vc_data *conp, int blank)
+promcon_blank(struct vc_data *conp, int blank, int mode_switch)
{
if (blank) {
promcon_puts("\033[H\033[J\033[7m \033[m\b", 15);
===== drivers/video/console/sticon.c 1.8 vs edited =====
--- 1.8/drivers/video/console/sticon.c Wed Jan 8 11:45:15 2003
+++ edited/drivers/video/console/sticon.c Fri Feb 27 17:24:42 2004
@@ -250,26 +250,18 @@
return 0;
}
-static int sticon_blank(struct vc_data *c, int blank)
+static int sticon_blank(struct vc_data *c, int blank, int mode_switch)
{
- switch (blank) {
- case 0: /* unblank */
- vga_is_gfx = 0;
- /* Tell console.c that it has to restore the screen itself */
- return 1;
- case 1: /* normal blanking */
- default: /* VESA blanking */
- if (vga_is_gfx)
- return 0;
- sticon_set_origin(c);
- sti_clear(sticon_sti, 0,0, c->vc_rows, c->vc_cols, BLANK);
- return 1;
- case -1: /* Entering graphic mode */
- sti_clear(sticon_sti, 0,0, c->vc_rows, c->vc_cols, BLANK);
- vga_is_gfx = 1;
+ if (blank == 0) {
+ if (mode_switch)
+ vga_is_gfx = 0;
return 1;
}
- return 1; /* console needs to restore screen itself */
+ sticon_set_origin(c);
+ sti_clear(sticon_sti, 0,0, c->vc_rows, c->vc_cols, BLANK);
+ if (mode_switch)
+ vga_is_gfx = 1;
+ return 1;
}
static int sticon_scrolldelta(struct vc_data *conp, int lines)
===== drivers/video/console/vgacon.c 1.15 vs edited =====
--- 1.15/drivers/video/console/vgacon.c Wed Mar 12 04:17:29 2003
+++ edited/drivers/video/console/vgacon.c Fri Feb 27 17:24:57 2004
@@ -76,7 +76,7 @@
static void vgacon_deinit(struct vc_data *c);
static void vgacon_cursor(struct vc_data *c, int mode);
static int vgacon_switch(struct vc_data *c);
-static int vgacon_blank(struct vc_data *c, int blank);
+static int vgacon_blank(struct vc_data *c, int blank, int mode_switch);
static int vgacon_font_op(struct vc_data *c, struct console_font_op *op);
static int vgacon_set_palette(struct vc_data *vc, unsigned char *table);
static int vgacon_scrolldelta(struct vc_data *c, int lines);
@@ -661,7 +661,7 @@
}
}
-static int vgacon_blank(struct vc_data *c, int blank)
+static int vgacon_blank(struct vc_data *c, int blank, int mode_switch)
{
switch (blank) {
case 0: /* Unblank */
@@ -678,7 +678,8 @@
/* Tell console.c that it has to restore the screen itself */
return 1;
case 1: /* Normal blanking */
- if (vga_video_type == VIDEO_TYPE_VGAC) {
+ case -1: /* Obsolete */
+ if (!mode_switch && vga_video_type == VIDEO_TYPE_VGAC) {
vga_pal_blank(&state);
vga_palette_blanked = 1;
return 0;
@@ -686,11 +687,8 @@
vgacon_set_origin(c);
scr_memsetw((void *) vga_vram_base, BLANK,
c->vc_screenbuf_size);
- return 1;
- case -1: /* Entering graphic mode */
- scr_memsetw((void *) vga_vram_base, BLANK,
- c->vc_screenbuf_size);
- vga_is_gfx = 1;
+ if (mode_switch)
+ vga_is_gfx = 1;
return 1;
default: /* VESA blanking */
if (vga_video_type == VIDEO_TYPE_VGAC) {
===== include/linux/console.h 1.11 vs edited =====
--- 1.11/include/linux/console.h Wed Feb 4 16:28:11 2004
+++ edited/include/linux/console.h Fri Feb 27 17:26:10 2004
@@ -37,7 +37,7 @@
int (*con_scroll)(struct vc_data *, int, int, int, int);
void (*con_bmove)(struct vc_data *, int, int, int, int, int, int);
int (*con_switch)(struct vc_data *);
- int (*con_blank)(struct vc_data *, int);
+ int (*con_blank)(struct vc_data *, int, int);
int (*con_font_op)(struct vc_data *, struct console_font_op *);
int (*con_resize)(struct vc_data *, unsigned int, unsigned int);
int (*con_set_palette)(struct vc_data *, unsigned char *);
===== include/linux/fb.h 1.60 vs edited =====
--- 1.60/include/linux/fb.h Mon Feb 16 04:07:11 2004
+++ edited/include/linux/fb.h Fri Feb 27 17:26:19 2004
@@ -152,6 +152,7 @@
#define FB_ACTIVATE_VBL 16 /* activate values on next vbl */
#define FB_CHANGE_CMAP_VBL 32 /* change colormap on vbl */
#define FB_ACTIVATE_ALL 64 /* change all VCs on this fb */
+#define FB_ACTIVATE_FORCE 128 /* force apply even when no change*/
#define FB_ACCELF_TEXT 1 /* text mode acceleration */
===== include/linux/vt_kern.h 1.9 vs edited =====
--- 1.9/include/linux/vt_kern.h Wed Mar 12 04:17:29 2003
+++ edited/include/linux/vt_kern.h Fri Feb 27 17:25:42 2004
@@ -44,7 +44,8 @@
void vc_disallocate(unsigned int console);
void reset_palette(int currcons);
void set_palette(int currcons);
-void do_blank_screen(int gfx_mode);
+void do_blank_screen(int entering_gfx);
+void do_unblank_screen(int leaving_gfx);
void unblank_screen(void);
void poke_blanked_console(void);
int con_font_op(int currcons, struct console_font_op *op);
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 10:06 ` arief#
@ 2004-02-27 9:56 ` Benjamin Herrenschmidt
2004-02-27 10:45 ` Zilvinas Valinskas
0 siblings, 1 reply; 14+ messages in thread
From: Benjamin Herrenschmidt @ 2004-02-27 9:56 UTC (permalink / raw)
To: arief#; +Cc: Linux Kernel list
On Fri, 2004-02-27 at 21:06, arief# wrote:
> Dear all.
>
>
> This patch from Benjamin solved my problem.
>
> To Zilvinas <zilvinas@gemtek.lt>, I've tried your suggestion to change
> my XF86Config-4 file to include UseFBDev line. But it doesnt work. It
> made my Xserver wont even start. But I'm not sure, it could be X problem
> (Debian Unstable got some updated X package that I haven't got a chance
> to upgrade to).
There is a problem with recent radeonfb's an X + UseFBDev. I think the
problem is that XFree is claiming a mode whose virtual resolution is very
large. I have to verify that (it works for me here). Radeonfb has
limitations on what it allows on the virtual resolution in recent
version to limit the ioremap'ing done in the kernel. Unfortunately,
there is no simple way to "detach" one from the other at this point.
I should modify radeonfb to crop the virtual resolution instead of
failing though...
Can you try hacking in drivers/video/aty/radeon_base.c, function
check_mode() and see why it fails ? (I think it's that function
that is failing).
Ben.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 7:04 ` Benjamin Herrenschmidt
@ 2004-02-27 10:06 ` arief#
2004-02-27 9:56 ` Benjamin Herrenschmidt
2004-02-27 17:19 ` Mike Houston
2004-02-27 18:00 ` James Simmons
2 siblings, 1 reply; 14+ messages in thread
From: arief# @ 2004-02-27 10:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux Kernel list
Dear all.
This patch from Benjamin solved my problem.
To Zilvinas <zilvinas@gemtek.lt>, I've tried your suggestion to change
my XF86Config-4 file to include UseFBDev line. But it doesnt work. It
made my Xserver wont even start. But I'm not sure, it could be X problem
(Debian Unstable got some updated X package that I haven't got a chance
to upgrade to).
Anyway, thanks for all who cared.
Regards
-arief
On Fri, 2004-02-27 at 14:04, Benjamin Herrenschmidt wrote:
> On Fri, 2004-02-27 at 17:27, arief# wrote:
> > Dear all,
> >
> >
> > Before, please cc me the answer, as I'm not on the list right now.
> >
> > In 2.6.3 (including -mmX patches), radeon framebuffer seems to having
> > problems. Everytime I do clear screen, it only 'half cleared'. I still
> > can see the mark of the previous texts in shaded mode. And it does not
> > do deletion well, too.
> >
> > Anybody else having the same problem?
>
> If it happens only after switching back from XFree, then it's a known
> problem. I have implemented a fix locally but got sidetracked before I
> could test it properly.
>
> Can you test the patch below ? :
>
> ===== drivers/char/vt.c 1.61 vs edited =====
> --- 1.61/drivers/char/vt.c Thu Feb 19 14:43:03 2004
> +++ edited/drivers/char/vt.c Fri Feb 27 17:27:09 2004
> @@ -2743,12 +2743,12 @@
> * Called only if powerdown features are allowed.
> */
> switch (vesa_blank_mode) {
> - case VESA_NO_BLANKING:
> - c->vc_sw->con_blank(c, VESA_VSYNC_SUSPEND+1);
> + case VESA_NO_BLANKING:
> + c->vc_sw->con_blank(c, VESA_VSYNC_SUSPEND+1, 0);
> break;
> - case VESA_VSYNC_SUSPEND:
> - case VESA_HSYNC_SUSPEND:
> - c->vc_sw->con_blank(c, VESA_POWERDOWN+1);
> + case VESA_VSYNC_SUSPEND:
> + case VESA_HSYNC_SUSPEND:
> + c->vc_sw->con_blank(c, VESA_POWERDOWN+1, 0);
> break;
> }
> }
> @@ -2776,7 +2776,7 @@
> if (entering_gfx) {
> hide_cursor(currcons);
> save_screen(currcons);
> - sw->con_blank(vc_cons[currcons].d, -1);
> + sw->con_blank(vc_cons[currcons].d, -1, 1);
> console_blanked = fg_console + 1;
> set_origin(currcons);
> return;
> @@ -2794,7 +2794,7 @@
>
> save_screen(currcons);
> /* In case we need to reset origin, blanking hook returns 1 */
> - i = sw->con_blank(vc_cons[currcons].d, 1);
> + i = sw->con_blank(vc_cons[currcons].d, 1, 0);
> console_blanked = fg_console + 1;
> if (i)
> set_origin(currcons);
> @@ -2808,14 +2808,14 @@
> }
>
> if (vesa_blank_mode)
> - sw->con_blank(vc_cons[currcons].d, vesa_blank_mode + 1);
> + sw->con_blank(vc_cons[currcons].d, vesa_blank_mode + 1, 0);
> }
>
>
> /*
> * Called by timer as well as from vt_console_driver
> */
> -void unblank_screen(void)
> +void do_unblank_screen(int leaving_gfx)
> {
> int currcons;
>
> @@ -2839,13 +2839,24 @@
> }
>
> console_blanked = 0;
> - if (sw->con_blank(vc_cons[currcons].d, 0))
> + if (sw->con_blank(vc_cons[currcons].d, 0, leaving_gfx))
> /* Low-level driver cannot restore -> do it ourselves */
> update_screen(fg_console);
> if (console_blank_hook)
> console_blank_hook(0);
> set_palette(currcons);
> set_cursor(fg_console);
> +}
> +
> +/*
> + * This is called by the outside world to cause a forced unblank, mostly for
> + * oopses. Currently, I just call do_unblank_screen(0), but we could eventually
> + * call it with 1 as an argument and so force a mode restore... that may kill
> + * X or at least garbage the screen but would also make the Oops visible...
> + */
> +void unblank_screen(void)
> +{
> + do_unblank_screen(0);
> }
>
> /*
> ===== drivers/char/vt_ioctl.c 1.34 vs edited =====
> --- 1.34/drivers/char/vt_ioctl.c Wed Feb 25 21:31:13 2004
> +++ edited/drivers/char/vt_ioctl.c Fri Feb 27 17:27:21 2004
> @@ -497,7 +497,7 @@
> */
> acquire_console_sem();
> if (arg == KD_TEXT)
> - unblank_screen();
> + do_unblank_screen(1);
> else
> do_blank_screen(1);
> release_console_sem();
> @@ -1103,7 +1103,7 @@
> if (old_vc_mode != vt_cons[new_console]->vc_mode)
> {
> if (vt_cons[new_console]->vc_mode == KD_TEXT)
> - unblank_screen();
> + do_unblank_screen(1);
> else
> do_blank_screen(1);
> }
> @@ -1138,7 +1138,7 @@
> if (old_vc_mode != vt_cons[new_console]->vc_mode)
> {
> if (vt_cons[new_console]->vc_mode == KD_TEXT)
> - unblank_screen();
> + do_unblank_screen(1);
> else
> do_blank_screen(1);
> }
> ===== drivers/video/fbmem.c 1.90 vs edited =====
> --- 1.90/drivers/video/fbmem.c Mon Feb 16 23:42:15 2004
> +++ edited/drivers/video/fbmem.c Fri Feb 27 17:25:21 2004
> @@ -943,7 +943,8 @@
> {
> int err;
>
> - if (memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> + if ((var->activate & FB_ACTIVATE_FORCE) ||
> + memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> if (!info->fbops->fb_check_var) {
> *var = info->var;
> return 0;
> ===== drivers/video/console/fbcon.c 1.109 vs edited =====
> --- 1.109/drivers/video/console/fbcon.c Mon Feb 16 05:22:04 2004
> +++ edited/drivers/video/console/fbcon.c Fri Feb 27 17:47:24 2004
> @@ -159,7 +159,7 @@
> static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
> int height, int width);
> static int fbcon_switch(struct vc_data *vc);
> -static int fbcon_blank(struct vc_data *vc, int blank);
> +static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
> static int fbcon_font_op(struct vc_data *vc, struct console_font_op *op);
> static int fbcon_set_palette(struct vc_data *vc, unsigned char *table);
> static int fbcon_scrolldelta(struct vc_data *vc, int lines);
> @@ -1696,14 +1696,23 @@
> return 1;
> }
>
> -static int fbcon_blank(struct vc_data *vc, int blank)
> +static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
> {
> unsigned short charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
> struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
> struct display *p = &fb_display[vc->vc_num];
>
> - if (blank < 0) /* Entering graphics mode */
> - return 0;
> + if (mode_switch) {
> + struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
> + struct fb_var_screeninfo var = info->var;
> +
> + if (blank) {
> + fbcon_cursor(vc, CM_ERASE);
> + return 0;
> + }
> + var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
> + fb_set_var(info, &var);
> + }
>
> fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
>
> ===== drivers/video/console/promcon.c 1.9 vs edited =====
> --- 1.9/drivers/video/console/promcon.c Wed Dec 11 14:49:09 2002
> +++ edited/drivers/video/console/promcon.c Fri Feb 27 17:24:34 2004
> @@ -463,7 +463,7 @@
> }
>
> static int
> -promcon_blank(struct vc_data *conp, int blank)
> +promcon_blank(struct vc_data *conp, int blank, int mode_switch)
> {
> if (blank) {
> promcon_puts("\033[H\033[J\033[7m \033[m\b", 15);
> ===== drivers/video/console/sticon.c 1.8 vs edited =====
> --- 1.8/drivers/video/console/sticon.c Wed Jan 8 11:45:15 2003
> +++ edited/drivers/video/console/sticon.c Fri Feb 27 17:24:42 2004
> @@ -250,26 +250,18 @@
> return 0;
> }
>
> -static int sticon_blank(struct vc_data *c, int blank)
> +static int sticon_blank(struct vc_data *c, int blank, int mode_switch)
> {
> - switch (blank) {
> - case 0: /* unblank */
> - vga_is_gfx = 0;
> - /* Tell console.c that it has to restore the screen itself */
> - return 1;
> - case 1: /* normal blanking */
> - default: /* VESA blanking */
> - if (vga_is_gfx)
> - return 0;
> - sticon_set_origin(c);
> - sti_clear(sticon_sti, 0,0, c->vc_rows, c->vc_cols, BLANK);
> - return 1;
> - case -1: /* Entering graphic mode */
> - sti_clear(sticon_sti, 0,0, c->vc_rows, c->vc_cols, BLANK);
> - vga_is_gfx = 1;
> + if (blank == 0) {
> + if (mode_switch)
> + vga_is_gfx = 0;
> return 1;
> }
> - return 1; /* console needs to restore screen itself */
> + sticon_set_origin(c);
> + sti_clear(sticon_sti, 0,0, c->vc_rows, c->vc_cols, BLANK);
> + if (mode_switch)
> + vga_is_gfx = 1;
> + return 1;
> }
>
> static int sticon_scrolldelta(struct vc_data *conp, int lines)
> ===== drivers/video/console/vgacon.c 1.15 vs edited =====
> --- 1.15/drivers/video/console/vgacon.c Wed Mar 12 04:17:29 2003
> +++ edited/drivers/video/console/vgacon.c Fri Feb 27 17:24:57 2004
> @@ -76,7 +76,7 @@
> static void vgacon_deinit(struct vc_data *c);
> static void vgacon_cursor(struct vc_data *c, int mode);
> static int vgacon_switch(struct vc_data *c);
> -static int vgacon_blank(struct vc_data *c, int blank);
> +static int vgacon_blank(struct vc_data *c, int blank, int mode_switch);
> static int vgacon_font_op(struct vc_data *c, struct console_font_op *op);
> static int vgacon_set_palette(struct vc_data *vc, unsigned char *table);
> static int vgacon_scrolldelta(struct vc_data *c, int lines);
> @@ -661,7 +661,7 @@
> }
> }
>
> -static int vgacon_blank(struct vc_data *c, int blank)
> +static int vgacon_blank(struct vc_data *c, int blank, int mode_switch)
> {
> switch (blank) {
> case 0: /* Unblank */
> @@ -678,7 +678,8 @@
> /* Tell console.c that it has to restore the screen itself */
> return 1;
> case 1: /* Normal blanking */
> - if (vga_video_type == VIDEO_TYPE_VGAC) {
> + case -1: /* Obsolete */
> + if (!mode_switch && vga_video_type == VIDEO_TYPE_VGAC) {
> vga_pal_blank(&state);
> vga_palette_blanked = 1;
> return 0;
> @@ -686,11 +687,8 @@
> vgacon_set_origin(c);
> scr_memsetw((void *) vga_vram_base, BLANK,
> c->vc_screenbuf_size);
> - return 1;
> - case -1: /* Entering graphic mode */
> - scr_memsetw((void *) vga_vram_base, BLANK,
> - c->vc_screenbuf_size);
> - vga_is_gfx = 1;
> + if (mode_switch)
> + vga_is_gfx = 1;
> return 1;
> default: /* VESA blanking */
> if (vga_video_type == VIDEO_TYPE_VGAC) {
> ===== include/linux/console.h 1.11 vs edited =====
> --- 1.11/include/linux/console.h Wed Feb 4 16:28:11 2004
> +++ edited/include/linux/console.h Fri Feb 27 17:26:10 2004
> @@ -37,7 +37,7 @@
> int (*con_scroll)(struct vc_data *, int, int, int, int);
> void (*con_bmove)(struct vc_data *, int, int, int, int, int, int);
> int (*con_switch)(struct vc_data *);
> - int (*con_blank)(struct vc_data *, int);
> + int (*con_blank)(struct vc_data *, int, int);
> int (*con_font_op)(struct vc_data *, struct console_font_op *);
> int (*con_resize)(struct vc_data *, unsigned int, unsigned int);
> int (*con_set_palette)(struct vc_data *, unsigned char *);
> ===== include/linux/fb.h 1.60 vs edited =====
> --- 1.60/include/linux/fb.h Mon Feb 16 04:07:11 2004
> +++ edited/include/linux/fb.h Fri Feb 27 17:26:19 2004
> @@ -152,6 +152,7 @@
> #define FB_ACTIVATE_VBL 16 /* activate values on next vbl */
> #define FB_CHANGE_CMAP_VBL 32 /* change colormap on vbl */
> #define FB_ACTIVATE_ALL 64 /* change all VCs on this fb */
> +#define FB_ACTIVATE_FORCE 128 /* force apply even when no change*/
>
> #define FB_ACCELF_TEXT 1 /* text mode acceleration */
>
> ===== include/linux/vt_kern.h 1.9 vs edited =====
> --- 1.9/include/linux/vt_kern.h Wed Mar 12 04:17:29 2003
> +++ edited/include/linux/vt_kern.h Fri Feb 27 17:25:42 2004
> @@ -44,7 +44,8 @@
> void vc_disallocate(unsigned int console);
> void reset_palette(int currcons);
> void set_palette(int currcons);
> -void do_blank_screen(int gfx_mode);
> +void do_blank_screen(int entering_gfx);
> +void do_unblank_screen(int leaving_gfx);
> void unblank_screen(void);
> void poke_blanked_console(void);
> int con_font_op(int currcons, struct console_font_op *op);
>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 9:56 ` Benjamin Herrenschmidt
@ 2004-02-27 10:45 ` Zilvinas Valinskas
0 siblings, 0 replies; 14+ messages in thread
From: Zilvinas Valinskas @ 2004-02-27 10:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: arief#, Linux Kernel list
On Fri, Feb 27, 2004 at 08:56:42PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2004-02-27 at 21:06, arief# wrote:
> > Dear all.
> >
> >
> > This patch from Benjamin solved my problem.
> >
> > To Zilvinas <zilvinas@gemtek.lt>, I've tried your suggestion to change
> > my XF86Config-4 file to include UseFBDev line. But it doesnt work. It
> > made my Xserver wont even start. But I'm not sure, it could be X problem
> > (Debian Unstable got some updated X package that I haven't got a chance
> > to upgrade to).
>
> There is a problem with recent radeonfb's an X + UseFBDev. I think the
> problem is that XFree is claiming a mode whose virtual resolution is very
> large. I have to verify that (it works for me here). Radeonfb has
> limitations on what it allows on the virtual resolution in recent
> version to limit the ioremap'ing done in the kernel. Unfortunately,
> there is no simple way to "detach" one from the other at this point.
>
> I should modify radeonfb to crop the virtual resolution instead of
> failing though...
>
> Can you try hacking in drivers/video/aty/radeon_base.c, function
> check_mode() and see why it fails ? (I think it's that function
> that is failing).
Not sure what was failing on Arief# laptop, here it works perfectly
fine. Hardware: Compaq EVO N800v, kernel 2.6.3 , frambuffer and
UseFBDev "true" just fine.
Without UseFBDev console had almost the same effects Arief has reported.
After "clear screen" ^L in console with X running in background, I see a
lot of artifacts ... UseFBDev made it go away.
BR
>
> Ben.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 7:04 ` Benjamin Herrenschmidt
2004-02-27 10:06 ` arief#
@ 2004-02-27 17:19 ` Mike Houston
2004-02-27 18:00 ` James Simmons
2 siblings, 0 replies; 14+ messages in thread
From: Mike Houston @ 2004-02-27 17:19 UTC (permalink / raw)
To: linux-kernel; +Cc: benh
On Fri, 27 Feb 2004 18:04:51 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> If it happens only after switching back from XFree, then it's a known
> problem. I have implemented a fix locally but got sidetracked before I
> could test it properly.
>
> Can you test the patch below ? :
>
> ===== drivers/char/vt.c 1.61 vs edited =====
> --- 1.61/drivers/char/vt.c Thu Feb 19 14:43:03 2004
> +++ edited/drivers/char/vt.c Fri Feb 27 17:27:09 2004
> @@ -2743,12 +2743,12 @@
That patch fixes the problem for me also, Benjamin. Thank you!
Now I have my proper framebuffer console fully usable again (I had switched to VESA fb console in the interrim and that was OK, but it was causing a conflict with the linear framebuffer handle, unable to allocate an mtrr and unable to use write combining on starting X/DRI)
ATI Technologies Inc Radeon RV200 QW [Radeon 7500] on i845 chipset.
Grogan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 7:04 ` Benjamin Herrenschmidt
2004-02-27 10:06 ` arief#
2004-02-27 17:19 ` Mike Houston
@ 2004-02-27 18:00 ` James Simmons
2004-02-27 22:43 ` Benjamin Herrenschmidt
2 siblings, 1 reply; 14+ messages in thread
From: James Simmons @ 2004-02-27 18:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: arief#, Linux Kernel list
> Can you test the patch below ? :
Just a couple of things. The idea of adding another field to
con_blank bothers me. I think the better approach is to add more flags.
> ===== drivers/char/vt.c 1.61 vs edited =====
> --- 1.61/drivers/char/vt.c Thu Feb 19 14:43:03 2004
> +++ edited/drivers/char/vt.c Fri Feb 27 17:27:09 2004
> @@ -2743,12 +2743,12 @@
> * Called only if powerdown features are allowed.
> */
> switch (vesa_blank_mode) {
> - case VESA_NO_BLANKING:
> - c->vc_sw->con_blank(c, VESA_VSYNC_SUSPEND+1);
> + case VESA_NO_BLANKING:
> + c->vc_sw->con_blank(c, VESA_VSYNC_SUSPEND+1, 0);
> ===== drivers/video/fbmem.c 1.90 vs edited =====
> --- 1.90/drivers/video/fbmem.c Mon Feb 16 23:42:15 2004
> +++ edited/drivers/video/fbmem.c Fri Feb 27 17:25:21 2004
> @@ -943,7 +943,8 @@
> {
> int err;
>
> - if (memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> + if ((var->activate & FB_ACTIVATE_FORCE) ||
> + memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> if (!info->fbops->fb_check_var) {
> *var = info->var;
> return 0;
Ug!!! Another flag. How about instead in fbcon.c we call set_par directly
instead of messing with fb_set_var.
Let me play with some ideas. I can have a another patch ready over the
weekend.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 18:00 ` James Simmons
@ 2004-02-27 22:43 ` Benjamin Herrenschmidt
2004-02-28 0:58 ` James Simmons
0 siblings, 1 reply; 14+ messages in thread
From: Benjamin Herrenschmidt @ 2004-02-27 22:43 UTC (permalink / raw)
To: James Simmons; +Cc: arief#, Linux Kernel list
On Sat, 2004-02-28 at 05:00, James Simmons wrote:
> > Can you test the patch below ? :
>
> Just a couple of things. The idea of adding another field to
> con_blank bothers me. I think the better approach is to add more flags.
Linus proposed the additional parameter approach ;
> > - if (memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> > + if ((var->activate & FB_ACTIVATE_FORCE) ||
> > + memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> > if (!info->fbops->fb_check_var) {
> > *var = info->var;
> > return 0;
>
> Ug!!! Another flag. How about instead in fbcon.c we call set_par directly
> instead of messing with fb_set_var.
Because fb_set_par is the proper interface, I want to get rid of all
the direct calls to the fbdev made by fbcon in the end. Calling
set_par directly will also skip the notification of the clients,
which may be just what we want for fbcon and harmful the day some
other client relies on that mecanism (and I already have one example
on ppc).
> Let me play with some ideas. I can have a another patch ready over the
> weekend.
Well... I was about to submit this one...
Ben.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-27 22:43 ` Benjamin Herrenschmidt
@ 2004-02-28 0:58 ` James Simmons
2004-02-28 1:37 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 14+ messages in thread
From: James Simmons @ 2004-02-28 0:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: arief#, Linux Kernel list
> > Just a couple of things. The idea of adding another field to
> > con_blank bothers me. I think the better approach is to add more flags.
>
> Linus proposed the additional parameter approach ;
Still don't care for it.
> > > - if (memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> > > + if ((var->activate & FB_ACTIVATE_FORCE) ||
> > > + memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
> > > if (!info->fbops->fb_check_var) {
> > > *var = info->var;
> > > return 0;
> >
> > Ug!!! Another flag. How about instead in fbcon.c we call set_par directly
> > instead of messing with fb_set_var.
>
> Because fb_set_par is the proper interface, I want to get rid of all
> the direct calls to the fbdev made by fbcon in the end. Calling
> set_par directly will also skip the notification of the clients,
> which may be just what we want for fbcon and harmful the day some
> other client relies on that mecanism (and I already have one example
> on ppc).
Rememeber we have to modify every driver then to support FB_ACTIVATE_FORCE.
You have to ask yourself what do you want to do exactly?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-28 0:58 ` James Simmons
@ 2004-02-28 1:37 ` Benjamin Herrenschmidt
2004-03-02 0:22 ` James Simmons
0 siblings, 1 reply; 14+ messages in thread
From: Benjamin Herrenschmidt @ 2004-02-28 1:37 UTC (permalink / raw)
To: James Simmons; +Cc: arief#, Linux Kernel list
> Rememeber we have to modify every driver then to support FB_ACTIVATE_FORCE.
> You have to ask yourself what do you want to do exactly?
No we don't. Only fbmem, and that's part of the patch. What we could
do is strip the FB_ACTIVATE_FORCE (and actually clear out the
activate field completely) when copying to the driver's var structure
in fb_set_var().
In fact, we should certainly fix fb_set_var to _ignore_ the activate
field when comparing the var structures... this is a bug in the
current version imho.
It's a bit difficult to fix it while keeping memcmp, except if we do
a local copy of the var structure, which would eat stack space...
One problem with unblank is that it can be called at interrupt time,
but I don't think that ever happens with mode_switch set to true.
So we may just kmalloc a local copy of the var...
Ben.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-02-28 1:37 ` Benjamin Herrenschmidt
@ 2004-03-02 0:22 ` James Simmons
2004-03-02 0:26 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 14+ messages in thread
From: James Simmons @ 2004-03-02 0:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: arief#, Linux Kernel list
> In fact, we should certainly fix fb_set_var to _ignore_ the activate
> field when comparing the var structures... this is a bug in the
> current version imho.
>
> It's a bit difficult to fix it while keeping memcmp, except if we do
> a local copy of the var structure, which would eat stack space...
Yeah its a old bug. I don't know of a clean way to do that.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-03-02 0:22 ` James Simmons
@ 2004-03-02 0:26 ` Benjamin Herrenschmidt
2004-03-02 3:08 ` Paul Jackson
0 siblings, 1 reply; 14+ messages in thread
From: Benjamin Herrenschmidt @ 2004-03-02 0:26 UTC (permalink / raw)
To: James Simmons; +Cc: arief#, Linux Kernel list
On Tue, 2004-03-02 at 11:22, James Simmons wrote:
> > It's a bit difficult to fix it while keeping memcmp, except if we do
> > a local copy of the var structure, which would eat stack space...
>
> Yeah its a old bug. I don't know of a clean way to do that.
Heh, well... we have 2 choices, that's as simple as that: field-by-field
compare, or local copy + memcmp. It'd probably go for the first one...
Ben.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-03-02 0:26 ` Benjamin Herrenschmidt
@ 2004-03-02 3:08 ` Paul Jackson
2004-03-02 7:50 ` Paul Jackson
0 siblings, 1 reply; 14+ messages in thread
From: Paul Jackson @ 2004-03-02 3:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: jsimmons, arief_m_utama, linux-kernel
> we have 2 choices
Hare-brained idea for 3rd choice - a pair of memcmp's, one on the early
part of struct fb_var_screeninfo before the activate field, the 2nd on
the remainder of that struct, after the activate field.
#include <stddef.h>
/*
* Compare two structs of type TYPE, except for structure member MEMBER.
* Return is < 0, 0 or > 0, just like memcmp().
*/
#define memcmp_all_but(s1, s2, TYPE, MEMBER) \
do { \
return _memcmp_all_but( \
s1, s2, sizeof(TYPE), \
offsetof(TYPE, MEMBER), \
sizeof((TYPE *)0)->MEMBER); \
} while (0)
/*
* Same as memcmp(s1, s2, n), except excludes the 'msz' bytes
* starting at 'moffset' bytes from the comparison. The 'm'
* in 'msz', and 'moffset' stands for Member of structure.
*/
int _memcmp_all_but(const void *s1, const void *s2, size_t n, moffset, msz)
{
int i;
i = memcmp(s1, s2, moffset);
if (i != 0)
return i;
return memcmp((char *)s1+moffset+msz, (char *)s2+moffset+msz, n-moffset-msz)
}
...
if ((var->activate & FB_ACTIVATE_FORCE) ||
memcmp_all_but(&info->var, var, struct fb_var_screeninfo, activate)) {
...
The above code is untried, untested, and probably insane.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Radeon Framebuffer Driver in 2.6.3?
2004-03-02 3:08 ` Paul Jackson
@ 2004-03-02 7:50 ` Paul Jackson
0 siblings, 0 replies; 14+ messages in thread
From: Paul Jackson @ 2004-03-02 7:50 UTC (permalink / raw)
To: Paul Jackson; +Cc: benh, jsimmons, arief_m_utama, linux-kernel
The "do { return ...; } while(0)" part was programmed
by a mind numbed robot.
This might be a step less insane for the macro part:
#define memcmp_all_but(s1, s2, TYPE, MEMBER) \
_memcmp_all_but(s1, s2, sizeof(TYPE), \
offsetof(TYPE, MEMBER), \
sizeof((TYPE *)0)->MEMBER);
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2004-03-02 7:51 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-27 6:27 Radeon Framebuffer Driver in 2.6.3? arief#
2004-02-27 7:04 ` Benjamin Herrenschmidt
2004-02-27 10:06 ` arief#
2004-02-27 9:56 ` Benjamin Herrenschmidt
2004-02-27 10:45 ` Zilvinas Valinskas
2004-02-27 17:19 ` Mike Houston
2004-02-27 18:00 ` James Simmons
2004-02-27 22:43 ` Benjamin Herrenschmidt
2004-02-28 0:58 ` James Simmons
2004-02-28 1:37 ` Benjamin Herrenschmidt
2004-03-02 0:22 ` James Simmons
2004-03-02 0:26 ` Benjamin Herrenschmidt
2004-03-02 3:08 ` Paul Jackson
2004-03-02 7:50 ` Paul Jackson
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.