Skip to contentSkip to conversation

fbdev api.

STATUS Tobias Rittweiler 3 participants 9 messages Dec 6, 2002 – Dec 7, 2002

Subsystems (2)
Framebuffer layer Console
lore
Share & tools
lore

Tobias Rittweiler

author
#0 lore raw

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

#1 lore raw
Quoted 9 lines · 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

Quoted 9 lines

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).

Quoted 9 lines

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?

drivers/video/console/fbcon.c +2 -0
diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
@@ -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 */
Quoted 10 lines
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

author
#2 lore raw

Hello Antonino,

Quoted 7 lines · you
Quoted 7 lines

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.

Quoted 9 lines
Quoted 9 lines

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.

Quoted 10 lines
Quoted 10 lines
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

Signature · 2 lines
cheers,
 Tobias
#3 lore raw
Quoted 8 lines

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 :-)

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines

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.

Quoted 4 lines

AD> Can you try this?
AD> [..diff..]

Yes, it fixes the problem, thanks.

Will apply.

Quoted 5 lines

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.

????

#4 lore raw
In reply to Tobias Rittweiler

On Sat, 2002-12-07 at 03:59, Tobias Rittweiler wrote:
[...]

Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
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

Quoted 8 lines

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.

drivers/video/console/fbcon.c +10 -7
diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
@@ -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.

drivers/video/riva/fbdev.c +14 -34

87 lines not on this page · raw message

author
#5 lore raw

Hello Antonino,

Quoted 10 lines · you
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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

Signature · 2 lines
cheers,
 Tobias
#6 lore raw
In reply to Antonino Daplas

drivers/video/console/fbcon.c line 363

Quoted 13 lines

diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c

drivers/video/console/fbcon.c +1 -1
@@ -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.

Quoted 4 lines
drivers/video/console/fbcon.c +0 -0
@@ -1987,12 +1993,9 @@
 		else
 			update_screen(vc->vc_num);
 		return 0;

drivers/video/console/fbcon.c line 1999

Quoted 10 lines
drivers/video/console/fbcon.c +3 -6
-	} 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.

Quoted 5 lines

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  [[email protected]] 	                ____/|
fbdev/console/gfx developer                             \ o.O|

http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net

#7 lore raw

On Sun, 2002-12-08 at 00:05, James Simmons wrote:
[...]

Quoted 6 lines

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

#8 lore raw
In reply to Antonino Daplas

drivers/video/console/fbcon.c line 1993

Quoted 13 lines

diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c

drivers/video/console/fbcon.c +2 -0
@@ -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 :-)