Bug 6106

Summary: EGA problem since 2.6.14
Product: Drivers Reporter: Rafal Olearski (olearski)
Component: Console/FramebuffersAssignee: Samuel Thibault (samuel.thibault)
Status: CLOSED CODE_FIX    
Severity: normal CC: samuel.thibault
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.14 Subsystem:
Regression: --- Bisected commit-id:
Attachments: disables vertical display end tinker on EGA boards
cursor size fix for EGA boards
cursor resize fix for EGA boards
cursor resize fix for EGA boards

Description Rafal Olearski 2006-02-19 13:49:47 UTC
Most recent kernel where this bug did not occur:2.6.13.5
Distribution:Slackware
Hardware Environment:Enhanced Graphics Adapter

Problem Description:
Function vgacon_doresize added to file drivers/video/console/vgacon.c makes mess
on my EGA when called during initialization.
Yes, I still posess some oryginal EGAs :)
I have tested this problem on following cards:
Genoa PEGA (GN00600)  A.D.1987
Paradise 38315B  A.D.1986
Victor Technologies GEGA 350 v2.4 A.D.1988

Best regards, Rafal
Comment 1 Samuel Thibault 2006-02-19 14:45:01 UTC
Hi,  Ah, unfortunately I haven't an EGA board any more :)  What kind of mess do you get? Split screen, wrong font size, scrolling screen, completely unsynchronized screen?  Regards, Samuel 
Comment 2 Rafal Olearski 2006-02-20 01:54:51 UTC
Hi, it looks like I'm the last one who is using EGAs :)
On each board I get slightly different results.
All of them have correct Hsync, all are losing Vsync.
On one board i get a piece of one line repeated through all the screen (piece
means something like first 8 scan lines of 8x14 font), on another I get three or
four lines of text repeated.
Also there happens some strange single characters (colorful).
Thats all I remember now, because I'm writing from memory.
In about ten hours I'll be able to check this exactly on my  hardware.

Regards, Rafal
Comment 3 Rafal Olearski 2006-02-20 15:43:39 UTC
Hi again,

Any attempt to write something to VGA_CRTC_OVERFLOW register ends with scrolling
and/or blinking screen, especially doing:

outb_p(VGA_CRTC_OVERFLOW, vga_video_port_reg);
r7 = inb_p(vga_video_port_val);
outb_p(VGA_CRTC_OVERFLOW, vga_video_port_reg);
outb_p(r7,vga_video_port_val);
i lethal for EGA.


Another problem discovered in 2.6.15.4 kernel is that calling:
vgacon_set_cursor_size(c->vc_x, 31, 30);
gives similar results - quickly scrolling piece of text.

Regards, Rafal
Comment 4 Samuel Thibault 2006-02-20 15:48:29 UTC
Ah, yes, that makes sense: the overflow register is a bit different on EGA. But my book says that it "has no sense" on EGA. Which value can you read from it? 
Comment 5 Samuel Thibault 2006-02-20 16:13:33 UTC
Hi,

My book doesn't say it, but other parts of vgacon.c say: the attempt to read the overflow register will fail on an EGA. So I guess you're getting random values? Do you still get vertical sync issues when writing 0xff to the overflow register?

Regards,
Samuel
Comment 6 Rafal Olearski 2006-02-20 16:38:12 UTC
Setting bit 0 causes screen to blink (period 0.5s empty screen / some texts)
writing anything with bit 0 set to 0 (especially 0xfe or 0) results with top six
scanlines of 8x8 font of one line repeated throuhg all the screen.
(on 'Paradise' board).

Regards, Rafal.
Comment 7 Rafal Olearski 2006-02-20 17:08:31 UTC
Just for the record:
For 'Genoa' it does not matter what was written to bit 0, - blinks all the time,
and 'Victor' scrolls three complete lines of text instead of one incomplete :)

Of course I didn't checked all 256 possible values of VGA_CRTC_OVERFLOW, but
checking each bit separately didn't gave any positive results.

 

Regards, Rafal.
Comment 8 Antonino Daplas 2006-02-20 17:38:24 UTC
> Another problem discovered in 2.6.15.4 kernel is that calling:
> vgacon_set_cursor_size(c->vc_x, 31, 30);
> gives similar results - quickly scrolling piece of text.

This method of hiding the cursor does not work in EGA (docs say it produces a
split cursor, looks worse in your case).  But Linus said that we can ignore EGA
these days :-)

Comment 9 Samuel Thibault 2006-02-21 00:43:36 UTC
Ok, but the content you're reading from the overflow is bogus: that register is write-only on EGA. Could you try to just write 0xff ? 
Comment 10 Rafal Olearski 2006-02-21 01:14:35 UTC
Yes, I tried, writing 0xff ( setting bit 0 ) causes screen to blink...
I think to myself that maybe VGA_CRTC_OVERFLOW must be written in sequence witch
other register(s)...
I'll proceed witch further tests in ten hours. Meanwhile I'm digging i my
fifteen year old archive for documentation ( 5.25
Comment 11 Rafal Olearski 2006-02-21 12:16:35 UTC
At last I've found the magic number for my EGAs CRTC_OVERFLOW,
it's 0x11 (bits 3 and 5-7 seems to make no difference).
Comment 12 Samuel Thibault 2006-02-21 15:35:48 UTC
Bits 5-7 should indeed be ignored by the board.  So 0x11 works? What font size are you using ? 25*16 is 400, which should set a few bits in the overflow register.  Well, anyway. The problem here is that EGA has almost only write-only registers, so that writing to the overflow register is unsafe. I'd say we really don't want to care about all overflow bits meaning (vertical sync, etc.), so I'll write a patch for not trying to tinker with vertical display end _on EGA_. The really needed purpose of my original patch was mostly to be able to change the horizontal display end, anyway (for stty cols 70 to work nicely). 
Comment 13 Rafal Olearski 2006-02-21 16:36:58 UTC
By default, these cards display 8x8 fonts, which means 200 scanlines.
I think solution you proposed is very good, fighting with that registers is
pointless.


Now 'the cursor riddle' :-)

calling :

outb_p(0x0a, vga_video_port_reg);
outb_p(1, vga_video_port_val);
outb_p(0x0b, vga_video_port_reg);
outb_p(7, vga_video_port_val);

from vgacon_doresize gives nice fat cursor,
same code called from vgacon_set_cursor_size gives fat cursor too, but also
causes kernel to hang writing to the screen repeatedly :

Call Trace:
vgacon_cursor
hide_cursor
vt_console_print
__call_console drivers
call_console drivers
release_console_sem
con_init
console_init
start_kernel

I noticed that  vgacon_set_cursor_size is called for each line written to the
screen during this process.
Comment 14 Samuel Thibault 2006-02-21 16:44:57 UTC
Created attachment 7435 [details]
disables vertical display end tinker on EGA boards

This is against 2.6.15.4 kernel.

Could you try it please?
Comment 15 Rafal Olearski 2006-02-21 17:14:03 UTC
Works great for me, thank you very much, cursor related problem remains of course.

Best regards, Rafal
Comment 16 Samuel Thibault 2006-02-21 17:16:20 UTC
> By default, these cards display 8x8 fonts, which means 200 scanlines.  Ok,
> this makes sense: display scanlines number is below 256, but total scanlines
> number is above 256, hence the needed bits in the overflow register. 
Comment 17 Samuel Thibault 2006-02-21 17:17:25 UTC
Could you try

stty cols 72

for checking that horizontal display size works on EGA?
Comment 18 Samuel Thibault 2006-02-21 17:18:30 UTC
Created attachment 7436 [details]
cursor size fix for EGA boards

This is against 2.6.15.4.

Could you try it please?
Comment 19 Rafal Olearski 2006-02-21 17:35:30 UTC
>cursor size fix for EGA boards
Sorry, it doesn't work.

>Could you try
>stty cols 72
I'll do it tomorrow, now its too late for me :)
Best regards, Rafal
Comment 20 Samuel Thibault 2006-02-21 17:47:01 UTC
> doesn't work

i.e. it is just the same as with vanilla kernel?

And actually, when you wrote:

> vgacon_set_cursor_size(c->vc_x, 31, 30);
> gives similar results - quickly scrolling piece of text.

"scrolling piece of text": wasn't this actually the Call trace which was
getting printed over and over?
Comment 21 Rafal Olearski 2006-02-21 17:57:42 UTC
>> doesn't work
>
> i.e. it is just the same as with vanilla kernel?
Yes it is.

> And actually, when you wrote:
>
>> vgacon_set_cursor_size(c->vc_x, 31, 30);
>> gives similar results - quickly scrolling piece of text.
>
> "scrolling piece of text": wasn't this actually the Call trace which was
> getting printed over and over?

Yes, it was. It's scrolling very quickly, so I wasn't able to tell what's on the
screen, until I inserted delay loop.
Comment 22 Samuel Thibault 2006-02-22 16:25:39 UTC
Ok. Isn't there anything between Call traces that could give us a clue about why such Call traces are printed? Does your kernel has spinlock debugging on? Could you try to replace in vgacon_set_cursor_size          curs = (curs & 0xc0) | from;         cure = (cure & 0xe0) | to;  with          curs = from;         cure = to;  (i.e. erasing previous content) 
Comment 23 Rafal Olearski 2006-02-22 16:55:26 UTC
>Could you try
>stty cols 72
I tried, it works very well!

> Could you try to replace in vgacon_set_cursor_size  ...
Yes, I conducted a lot of tests with different values and all I found was that
it did not matter what was written, but when (and feeling of being stupid).

I started to experiment with dip switches on my EGAs and found that setting SW5
from ON to OFF solves the 'cursor related problem' :)
Not all of my (currently four) EGAs were affected, now all are working fine, so
if no one else complains about that, this probably was my own hardware
misconfiguration.

Also I found that using these switches, EGAs default text mode can be chosen
between 8x8 font 
Comment 24 Samuel Thibault 2006-02-22 17:01:50 UTC
Do you have documentation about this switch? Which board was this?

My cursor patch still applies anyway: the bold cursor should actually be a
non-visible cursor :)
Could you try to apply my cursor patch, and run

tput civis

for checking that the cursor becomes invisible. (run tput cnorm for getting back
a visible cursor).
Comment 25 Rafal Olearski 2006-02-22 17:58:09 UTC
It was the 'Paradise' board - the best one in my opinion.

it seems that first 4 switches are standard, the rest ? I'm not so sure.

I didn't found documentation for any of my boards :(

http://www.seasip.info/AmstradXT/1640tech/section1.html#1.22 says:
sw5:
    OFF for true EGA mode.
    ON for CGA/MDA/HERC emulation modes.
    (Also called 6845 compatible modes.)

Also look at:
http://www.seasip.info/AmstradXT/pc1640dip.html

According to these descriptions, my current setting ON ON ON off off should mean
350 scanlines which is not true. :(


And:
http://www.chips.navy.mil/archives/87_may/file7.htm
:)
and:
http://pdos.csail.mit.edu/6.828/2004/readings/hardware/vgadoc/EGAREGS.TXT
It seems that first four switches can be read through 'Input Status #0 Register'

The biggest problem with the cursor on some EGAs is that it appears two
characters  to the east of its actual position - fata morgana :)... I'll play
with it tomorrow...
Comment 26 Rafal Olearski 2006-02-23 16:52:17 UTC
> Could you try to apply my cursor patch...

I tried, it works very well on all my cards under condition that 

curs = from;
cure = to;
is also  done instead of reading old values.

If not, strange things are going on. On Genoa, for example, one can see a three
character long cursor  while it should be hidden. Or cursor displaced two
columns rightward.

Maybe You could replace 0x0a and 0x0b with VGA_CRTC_CURSOR_START and
VGA_CRTC_CURSOR_END respectively for better look ?

Best regards, Rafał
Comment 27 Samuel Thibault 2006-02-24 01:59:14 UTC
Hi,  Ah, it's interesting: that means that merely reading the ega register makes your card go crazy? I'll attach another try.  "I tried, it works very well on all my cards"  I.e. the cursor disappears as appropriate?  About numbers vs macros, yes, it looks better. But there are a lot of such to correct in the file :)  Regards, Samuel 
Comment 28 Samuel Thibault 2006-02-24 02:04:53 UTC
Created attachment 7464 [details]
cursor resize fix for EGA boards

This corrects cursor resize on ega boards: the register is write-only, so don't
even try to read it (it seems to trigger some NMI or something). And on ega,
31/30 produces a flat cursor. Using 31/31 is better: except with 32 pixels high
fonts, it shouldn't show up.
Comment 29 Samuel Thibault 2006-02-24 02:12:32 UTC
Created attachment 7465 [details]
cursor resize fix for EGA boards

Sorry, previous patch was not cleaned up...
Comment 30 Rafal Olearski 2006-02-24 05:47:15 UTC
>Hi,  Ah, it's interesting: that means that merely reading the ega
>register makes your card go crazy?
Hi,	No,  We miss understood, I'm doing too many shortcuts :)
replacing :
curs = (curs & 0xc0) | from;
cure = (cure & 0xe0) | to;
with :
curs = from;
cure = to;
Is required because writing 1's to bits 4-7 of  CRTC_CURSOR_START and
CRTC_CURSOR_END makes her go crazy :)
Probably bits 5-6 of  CRTC_CURSOR_END are so important.

So if we can't read these registers, we don't need to do that :)
Attempts to read these registers makes no harm.
Thats what I mean :)


>I.e. the cursor disappears as appropriate?

Yes, it disappears and appears back as it should, wonderful !

I'll test patch in eight hours...
Comment 31 Samuel Thibault 2006-02-24 06:01:44 UTC
Ok, I understand, but then reading them is useless, since curs = from; and cure = to; erase the read values :)

So, confirm that the patch works well, and I'll submit it to akpm.
Comment 32 Rafal Olearski 2006-02-24 16:06:24 UTC
Yes, the patch is ok.

Best regards, Rafal.
Comment 33 Rafal Olearski 2006-02-26 16:49:54 UTC
Once more I performed tests on all my EGAs, and found that problems with cursor
was caused by writing undefined values to bits 5-6 of CRTC_CURSOR_START
and CRTC_CURSOR_END only,
and calling:
vgacon_set_cursor_size(c->vc_x, 31, 31);
instead of:
vgacon_set_cursor_size(c->vc_x, 31, 30);

is not required for my cards and can be removed from the patch.

In fact putting 31 for cursor_start and anything from 0 to 31 for cursor_end,
makes it clearly invisible :)