Re: [STATUS] fbdev api.

Re: [STATUS] fbdev api.

[Tobias Rittweiler]

Hello James,

Monday, December 2, 2002, 10:07:33 PM, you wrote:

JS> Hi!

JS> I have a new patch avaiable. It is against 2.5.50. The patch is at
JS> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Besides the hunks posted recently, I encountered three problems/bugs:

a) Although your patch fixes the FB oddness for me, it makes booting
   without using framebuffer fail, IOW the kernel hangs:

   Video mode to be used for restore is f00
   BIOS-provided physical RAM map:
    BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)

b) After returning from blanking mode (via APM) to normal mode, no
   character is drawn. Let's assume I'm using VIM when that happens:
   After putting any character to return from blank mode, the screen stays
   blanked apart from the cursor that _is_ shown. Now I'm able to move
   the cursor, and when the cursor encounters a character, this char
   is drawn (and keeps drawn). Though when I press Ctrl-L or when I go one line
   above to the current top-line (i.e. by forcing a redrawn), the
   whole screen is drawn properly.

c) instruction:          | produces:
   ======================|==================
   1. typing abc def     | $ abc def
                         |          ^ (<- cursor)
   2. going three chars  | $ abc def
      ro the left        |       ^
   3. pressing backspace | $ abcddef
                         |      ^
   4. pressing enter     | -bash: abcdef: command not found
                         |

HTH.
--
cheers,
 Tobias

Re[2]: [STATUS] fbdev api.

[Tobias Rittweiler]

Hello Antonino,

Saturday, December 7, 2002, 12:55:34 AM, you wrote:

>> a) Although your patch fixes the FB oddness for me, it makes booting
>>    without using framebuffer fail, IOW the kernel hangs:
>> 
>>    Video mode to be used for restore is f00
>>    BIOS-provided physical RAM map:
>>     BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
>> 
AD> Do you have framebuffer console enabled but with no framebuffer device
AD> enabled at boot time?  This will always fail with James' current patch.

AD> The diff I submitted in one of my replies in this thread (fbcon.diff)
AD> might fix that (not sure).

Thanks, that patches fixes it.


>> b) After returning from blanking mode (via APM) to normal mode, no
>>    character is drawn. Let's assume I'm using VIM when that happens:
>>    After putting any character to return from blank mode, the screen stays
>>    blanked apart from the cursor that _is_ shown. Now I'm able to move
>>    the cursor, and when the cursor encounters a character, this char
>>    is drawn (and keeps drawn). Though when I press Ctrl-L or when I go one line
>>    above to the current top-line (i.e. by forcing a redrawn), the
>>    whole screen is drawn properly.
>> 
AD> Can you try this?
AD> [..diff..]

Yes, it fixes the problem, thanks.


>> c) instruction:          | produces:
>>    ======================|==================
>>    1. typing abc def     | $ abc def
>>                          |          ^ (<- cursor)
>>    2. going three chars  | $ abc def
>>       ro the left        |       ^
>>    3. pressing backspace | $ abcddef
>>                          |      ^
>>    4. pressing enter     | -bash: abcdef: command not found
>>                          |

AD> I get this also. Seems to occur only with colored terms.  When I do 

AD> set TERM=vt100

AD> the problem disappears, so I thought this was an isolated case with my
AD> setup :-). Similar glitches happen also in emacs with syntax
AD> highlighting turned on.

Still there.


AD> Tony
-- 
cheers,
 Tobias

Re[2]: [STATUS] fbdev api.

[James Simmons]

> AD> Do you have framebuffer console enabled but with no framebuffer device
> AD> enabled at boot time?  This will always fail with James' current patch.
> 
> AD> The diff I submitted in one of my replies in this thread (fbcon.diff)
> AD> might fix that (not sure).
> 
> Thanks, that patches fixes it.

The fix is in the latest BK tree as well so Linus will get the fix :-)

> >> b) After returning from blanking mode (via APM) to normal mode, no
> >>    character is drawn. Let's assume I'm using VIM when that happens:
> >>    After putting any character to return from blank mode, the screen stays
> >>    blanked apart from the cursor that _is_ shown. Now I'm able to move
> >>    the cursor, and when the cursor encounters a character, this char
> >>    is drawn (and keeps drawn). Though when I press Ctrl-L or when I go one line
> >>    above to the current top-line (i.e. by forcing a redrawn), the
> >>    whole screen is drawn properly.
> >> 
> AD> Can you try this?
> AD> [..diff..]
>
> Yes, it fixes the problem, thanks.

Will apply.

> AD> the problem disappears, so I thought this was an isolated case with my
> AD> setup :-). Similar glitches happen also in emacs with syntax
> AD> highlighting turned on.
> 
> Still there.

 ????

Re: [STATUS] fbdev api.

[Antonino Daplas]

On Sat, 2002-12-07 at 00:42, Tobias Rittweiler wrote:
> Hello James,
> 
> Monday, December 2, 2002, 10:07:33 PM, you wrote:
> 
> JS> Hi!
> 
> JS> I have a new patch avaiable. It is against 2.5.50. The patch is at
> JS> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Besides the hunks posted recently, I encountered three problems/bugs:
> 
> a) Although your patch fixes the FB oddness for me, it makes booting
>    without using framebuffer fail, IOW the kernel hangs:
> 
>    Video mode to be used for restore is f00
>    BIOS-provided physical RAM map:
>     BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
> 
Do you have framebuffer console enabled but with no framebuffer device
enabled at boot time?  This will always fail with James' current patch.

The diff I submitted in one of my replies in this thread (fbcon.diff)
might fix that (not sure).

> b) After returning from blanking mode (via APM) to normal mode, no
>    character is drawn. Let's assume I'm using VIM when that happens:
>    After putting any character to return from blank mode, the screen stays
>    blanked apart from the cursor that _is_ shown. Now I'm able to move
>    the cursor, and when the cursor encounters a character, this char
>    is drawn (and keeps drawn). Though when I press Ctrl-L or when I go one line
>    above to the current top-line (i.e. by forcing a redrawn), the
>    whole screen is drawn properly.
> 
Can you try this?

diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.50-js/drivers/video/console/fbcon.c	2002-12-06 23:33:56.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2002-12-06 23:33:18.000000000 +0000
@@ -1986,6 +1986,8 @@
 						 vc->vc_cols);
 			vc->vc_video_erase_char = oldc;
 		}
+		else
+			update_screen(vc->vc_num);
 		return 0;
 	} else {
 		/* Tell console.c that it has to restore the screen itself */

> c) instruction:          | produces:
>    ======================|==================
>    1. typing abc def     | $ abc def
>                          |          ^ (<- cursor)
>    2. going three chars  | $ abc def
>       ro the left        |       ^
>    3. pressing backspace | $ abcddef
>                          |      ^
>    4. pressing enter     | -bash: abcdef: command not found
>                          |

I get this also. Seems to occur only with colored terms.  When I do 

set TERM=vt100

the problem disappears, so I thought this was an isolated case with my
setup :-). Similar glitches happen also in emacs with syntax
highlighting turned on.

Tony

Re: [STATUS] fbdev api.

[James Simmons]

> diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
> --- linux-2.5.50-js/drivers/video/console/fbcon.c	2002-12-06 23:33:56.000000000 +0000
> +++ linux/drivers/video/console/fbcon.c	2002-12-06 23:33:18.000000000 +0000
> @@ -1986,6 +1986,8 @@
>  						 vc->vc_cols);
>  			vc->vc_video_erase_char = oldc;
>  		}
> +		else
> +			update_screen(vc->vc_num);
>  		return 0;
>  	} else {
>  		/* Tell console.c that it has to restore the screen itself */

Applied :-)

Re[4]: [STATUS] fbdev api.

[Tobias Rittweiler]

Hello Antonino,

Saturday, December 7, 2002, 11:22:07 AM, you wrote:

>> >> c) instruction:          | produces:
>> >>    ======================|==================
>> >>    1. typing abc def     | $ abc def
>> >>                          |          ^ (<- cursor)
>> >>    2. going three chars  | $ abc def
>> >>       ro the left        |       ^
>> >>    3. pressing backspace | $ abcddef
>> >>                          |      ^
>> >>    4. pressing enter     | -bash: abcdef: command not found
>> >>                          |

AD> Can you try this? It should fix the problem you mentioned as well as the
AD> emacs glitch.  Also, a quick fix for character map generation failures
AD> (KDFONTOP ioctl), ie when selecting console fonts.  Finally, if fbdev
AD> supports blanking, let's use that.
AD> [..patch..]
 
Ah, good job! Now working at the shell prompt is usable again. Many
thanks for your time exposure.

AD> Tony
-- 
cheers,
 Tobias

Re: Re[2]: [STATUS] fbdev api.

[Antonino Daplas]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

On Sat, 2002-12-07 at 03:59, Tobias Rittweiler wrote:
[...]
> >> c) instruction:          | produces:
> >>    ======================|==================
> >>    1. typing abc def     | $ abc def
> >>                          |          ^ (<- cursor)
> >>    2. going three chars  | $ abc def
> >>       ro the left        |       ^
> >>    3. pressing backspace | $ abcddef
> >>                          |      ^
> >>    4. pressing enter     | -bash: abcdef: command not found
> >>                          |
> 
> AD> I get this also. Seems to occur only with colored terms.  When I do 
> 
> AD> set TERM=vt100
> 
> AD> the problem disappears, so I thought this was an isolated case with my
> AD> setup :-). Similar glitches happen also in emacs with syntax
> AD> highlighting turned on.
> 
> Still there.
> 
Can you try this? It should fix the problem you mentioned as well as the
emacs glitch.  Also, a quick fix for character map generation failures
(KDFONTOP ioctl), ie when selecting console fonts.  Finally, if fbdev
supports blanking, let's use that.

diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.50-js/drivers/video/console/fbcon.c	2002-12-07 10:10:40.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2002-12-07 10:12:11.000000000 +0000
@@ -357,7 +357,7 @@
 	area.dx = dx * vc->vc_font.width;
 	area.dy = dy * vc->vc_font.height;
 	area.height = height * vc->vc_font.height;
-	area.width = width * vc->vc_font.height;
+	area.width = width * vc->vc_font.width;
 
 	info->fbops->fb_copyarea(info, &area);
 }
@@ -910,6 +910,12 @@
 
 	info->var.xoffset = info->var.yoffset = p->yscroll = 0;	/* reset wrap/pan */
 
+	/*
+	 * FIXME: need to set this in order for KDFONTOP ioctl
+	 *        to work 
+	 */
+	p->fontwidthmask = FONTWIDTHRANGE(1,16);
+
 	for (i = 0; i < MAX_NR_CONSOLES; i++)
 		if (i != con && fb_display[i].fb_info == info &&
 		    fb_display[i].conp && fb_display[i].fontdata)
@@ -1987,12 +1993,9 @@
 		else
 			update_screen(vc->vc_num);
 		return 0;
-	} else {
-		/* Tell console.c that it has to restore the screen itself */
-		return 1;
-	}
-	fb_blank(blank, info);
-	return 0;
+	} 
+	else 
+		return info->fbops->fb_blank(blank, info);
 }
 
 static void fbcon_free_font(struct display *p)

Tony

PS: James, can you also apply the following riva cleanup patch.  It
fixes compile failures as well as removal of unused defines and
declarations.

Thanks.



[-- Attachment #2: rivafb.diff --]
[-- Type: text/x-patch, Size: 2999 bytes --]

diff -Naur linux-2.5.50-js/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.50-js/drivers/video/riva/fbdev.c	2002-12-07 09:50:22.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c	2002-12-07 09:53:45.000000000 +0000
@@ -214,31 +214,6 @@
 };
 MODULE_DEVICE_TABLE(pci, rivafb_pci_tbl);
 
-
-
-/* ------------------------------------------------------------------------- *
- *
- * framebuffer related structures
- *
- * ------------------------------------------------------------------------- */
-
-extern struct display_switch fbcon_riva8;
-extern struct display_switch fbcon_riva16;
-extern struct display_switch fbcon_riva32;
-
-struct riva_cursor {
-	int enable;
-	int on;
-	int vbl_cnt;
-	int last_move_delay;
-	int blink_rate;
-	struct {
-		u16 x, y;
-	} pos, size;
-	unsigned short image[MAX_CURS*MAX_CURS];
-	struct timer_list *timer;
-};
-
 /* ------------------------------------------------------------------------- *
  *
  * global variables
@@ -1167,7 +1142,7 @@
 
 	if (!cnt) {
 		memset(&par->state, 0, sizeof(struct fb_vgastate));
-		par->state.flags = VGA_SAVE_MODE  | VGA_SAVE_FONTS;
+		par->state.flags = VGA_SAVE_MODE  | VGA_SAVE_FONT0;
 		/* save the DAC for Riva128 */
 		if (par->riva.Architecture == NV_ARCH_03)
 			par->state.flags |= VGA_SAVE_CMAP;
@@ -1189,11 +1164,10 @@
 	if (!cnt)
 		return -EINVAL;
 	if (cnt == 1) {
-		par->riva.LockUnlock(&par->riva, 0);
-		par->riva.LoadStateExt(&par->riva, &par->initial_state.ext);
+		riva_load_state(par, &par->initial_state);
+		par->riva.LockUnlock(&par->riva, 1);
 
 		fb_restore_vga(&par->state);
-		par->riva.LockUnlock(&par->riva, 1);
 	}
 
 	atomic_dec(&par->ref_count);
@@ -1566,6 +1540,16 @@
 		fb_find_mode(&info->var, info, mode_option,
 			     NULL, 0, NULL, 8);
 #endif
+
+	info->var.yres_virtual = -1;
+	info->var.xres_virtual = info->var.xres;
+	if (rivafb_check_var(&info->var, info))
+		return 1;
+
+	info->fix.line_length = (info->var.xres_virtual * (info->var.bits_per_pixel >> 3));
+	info->fix.visual = (info->var.bits_per_pixel == 8) ? 
+				FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
+	
 	return 0;
 }
 
@@ -1883,10 +1867,8 @@
 	while ((this_opt = strsep(&options, ",")) != NULL) {
 		if (!*this_opt)
 			continue;
-		if (!strncmp(this_opt, "nomove", 6)) {
-			nomove = 1;
 #ifdef CONFIG_MTRR
-		} else if (!strncmp(this_opt, "nomtrr", 6)) {
+		if (!strncmp(this_opt, "nomtrr", 6)) {
 			nomtrr = 1;
 #endif
 		} else
@@ -1935,8 +1917,6 @@
 MODULE_PARM_DESC(font, "Specifies one of the compiled-in fonts (default=none)");
 MODULE_PARM(noaccel, "i");
 MODULE_PARM_DESC(noaccel, "Disables hardware acceleration (0 or 1=disabled) (default=0)");
-MODULE_PARM(nomove, "i");
-MODULE_PARM_DESC(nomove, "Enables YSCROLL_NOMOVE (0 or 1=enabled) (default=0)");
 #ifdef CONFIG_MTRR
 MODULE_PARM(nomtrr, "i");
 MODULE_PARM_DESC(nomtrr, "Disables MTRR support (0 or 1=disabled) (default=0)");

Re: Re[2]: [STATUS] fbdev api.

[James Simmons]

> diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
> --- linux-2.5.50-js/drivers/video/console/fbcon.c	2002-12-07 10:10:40.000000000 +0000
> +++ linux/drivers/video/console/fbcon.c	2002-12-07 10:12:11.000000000 +0000
> @@ -357,7 +357,7 @@
>  	area.dx = dx * vc->vc_font.width;
>  	area.dy = dy * vc->vc_font.height;
>  	area.height = height * vc->vc_font.height;
> -	area.width = width * vc->vc_font.height;
> +	area.width = width * vc->vc_font.width;
>
>  	info->fbops->fb_copyarea(info, &area);
>  }

Ug!!! A nasty typo. Thanks.

> @@ -1987,12 +1993,9 @@
>  		else
>  			update_screen(vc->vc_num);
>  		return 0;
> -	} else {
> -		/* Tell console.c that it has to restore the screen itself */
> -		return 1;
> -	}
> -	fb_blank(blank, info);
> -	return 0;
> +	}
> +	else
> +		return info->fbops->fb_blank(blank, info);
>  }

Hm. I have something similiar. That code needs to be cleaned up.

> Tony
>
> PS: James, can you also apply the following riva cleanup patch.  It
> fixes compile failures as well as removal of unused defines and
> declarations.

Most of those fixes I already have in BK. I think yres_virtual being
set to -1 is wrong. Also do we really need to call check var? The default
mode is "trusted". Also fb_find_mode when we use it calls check_var.
default_var already has the correct virtual res info. We do need to set
fix tho :-)  Thanks for the fixes.

@@ -1566,6 +1540,16 @@
                fb_find_mode(&info->var, info, mode_option,
                             NULL, 0, NULL, 8);
 #endif
+
+       info->var.yres_virtual = -1;
+       info->var.xres_virtual = info->var.xres;
+       if (rivafb_check_var(&info->var, info))
+               return 1;
+
+       info->fix.line_length = (info->var.xres_virtual * (info->var.bits_per_pi
+       info->fix.visual = (info->var.bits_per_pixel == 8) ?
+                               FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_DIRECTCOLOR;
+
        return 0;


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  [jsimmons@users.sf.net] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Re[2]: [STATUS] fbdev api.

[Antonino Daplas]

On Sun, 2002-12-08 at 00:05, James Simmons wrote:
[...]
> Most of those fixes I already have in BK. I think yres_virtual being
> set to -1 is wrong. Also do we really need to call check var? The default
> mode is "trusted". Also fb_find_mode when we use it calls check_var.
> default_var already has the correct virtual res info. We do need to set
> fix tho :-)  Thanks for the fixes.
> 
That's okay James, the code that calls check_var() during init  is a
"temporary" code.  Rivafb happens to have a do_maximize() function that
computes for the highest yres_virtual when it's -1.  Currently, since
using fbset is broken, I do that to enable ypanning.  But it's not
important.

Tony