From: Antonino A. D. <ad...@gm...> - 2005-11-18 20:24:15
|
Knut Petersen wrote: > Hi Antonino, > > For rotation values of 1 and 3 in combination with unusual font heights > there are > serious cursor problems: > > standard 8x16 and arial 22x24: ok > comic 16x26 and bitstream 16x30: broken as described below. > > 1: Load e.g. bitstream 16x30 font and switch to rotation 1. > 2: At the bash prompt, type "asdf > qwer" without the quotation marks > and without > hitting enter. > 3: Try to delete the letters q,w,e,r and reenter them. Everything works > fine. > 4: Now place the cursor immediately behind the letter f and delete it. > Everything ok. > 5. Hit the key f to reenter that letter .... now something breaks: > a: an f is inserted at the correct position > b: an f flashes for a short period at the place of the first space, > then it is overwritten > by the correct space character and the blinking cursor > c: the > at the right of the cursor is permanently overwritten with a > blank and a > frozen underline of the cursor, the line now reads asdf _ _ qwer. > > Deleting and reinserting the other characters before the > gives similar > results, e.g. > for the letter s the result is "asdd > qwer", the first d switching from > s to d fast but > visible and with the blinking cursor, the 2nd d (that should be an f) > permanently > underlined. > > No problems are visible if only one string of letters (even a long one) > is entered and > edited at the bash prompt. > > Any idea where to start? Can you reproduce the odd behaviour? This one I cannot reproduce. Have you tried reproducing it with vesafb? Any message in the log, such as a kernel oops? Your description sounds like a corruption of cursor->mask and cursor->image.data. > My first > idea was > to look into ccw_cursor() and cw_cursor(), but as there are no errors > for long strings > if they do not contain spaces, > or other signs of a special meaning to > bash, I suppose > that this is not the right/only place to start. My system is slow (Via > Eden cpu, 533Mhz), > could it be that the bug is invisible on faster machines? ... You can also try enabling a non-blinking block cursor (Documentation/VGA-softcursor.txt) to isolate the problem. With a non-blinking block cursor, fbcon's cursor is disabled and vt.c's softcursor takes over. You also said that the cursor becomes fixed. You can comment out the call to ops->cursor in fb_flashcursor in fbcon.c so you get a fixed cursor and eliminate the cursor blink pathway from the debugging. Tony |