Problems with text display in VL console

[Colonel Panic]

Hi. I'm one of your "vintage machine" users, having a computer with a Pentium III Coppermine (866 MHz) processor, a 30 GB hard drive and 512 MB of Ram.. I've recently downloaded and installed Vector 7.0 Beta, and for the most part it works very well.

However,  I've recently been using an old Matrox Millennium 3D card (4MB of video RAM) and I've encountered a problem with this. It works pretty well as long as I'm in X Windows mode, but when I switch to the bare console the edges of the screen "overflow" so that I can't see, for example, either side of the file listings in Midnight Commander properly, or the whole of the word "root" in the standard "root: #" command prompt.

I've tried changing the screen mode from 80x25 to something with a different number of columns, but to no avail; it boots into a console of 28 lines depth and 80 columns wide  (but with overhang) whatever I set.

Has anyone got any idea of what could be wrong, and how it could be fixed short of getting another video card?

Thanks in advance,

Colonel Panic .

P.S. I should perhaps point out that this is not just a problem I have in Vector 7 Beta, but it also happens in other Linux distros I've tried as well as in previous versions of Vector. Also, the "overhang" I'm talking about doesn't happen when the computer is actually booting up; it only manifests when the computer has actually finished booting.

[nightflier]

Sounds like the monitor modes need to be tweaked. Can you adjust the image to fit the screen using the hardware buttons on the monitor itself?

[Colonel Panic]

Thanks for your reply.

No, there aren't any such buttons on my monitor, or at least not ones that work (it's an old Compaq V50 15" CRT). And the funny thing is that none of the modes work; I get 28 lines per screenful whichever mode I select on bootup.

Also, if it's simply a hardware fault, why does it not show itself when the computer is still booting?

I didn't have this problem with my old video card, but that one used onboard RAM and some Linux distros wouldn't work in XOrg with it at all (hence the change). Nor do I have any problems with X Windows; it's only the console that's affected.

[rm-r]

Presuming you meant Ctrl+Alt+tty F1 <> F6
Usually F1 is boot-up, F7 reserved for GUI desktop (Distros vary on that)

Edit lilo.conf
(Example: Include line)  Vga=791 (see URL, choose from list)
(Alternate example) append="video=vesafb:mtrr,ywrap,1024x768-32@85"

640x480 vga=769
800x600 vga=771
1024x768 vga=773
1280x1024 vga=775
1600x1200 vga=796

This sets frame buffer/virtual sizes @ text boot-up or dropping to TTY
--------------------------------------------------------------------------
Reference:

VGA= (MODE)    Specifies the VGA text mode that should be selected when booting.
The following values are recognized (case is ignored):
    normal
        select normal 80x25 text mode.
    extended
        select 80x50 text mode. The word extended can be abbreviated to ext.
    ask
        stop and ask for user input (at boot time).
    number
        use the corresponding text mode. A list of available modes can be obtained by booting with vga=ask and pressing [Enter].

If this variable is omitted, the VGA mode setting contained in the kernel image is used.
rdev supports manipulation of the VGA text mode setting in the kernel image.

HTH

[rm-r]

Colonel

some Linux distros wouldn't work in XOrg

That sounds like wrong driver used for Xorg
Example ~ Legacy Matrox cards had no Linux support
Vesa was the generic driver to use for  xorg.conf

@ installation, if  probe cannot access DMA of vid card/monitor_edid  device/s,
or chipset  firmware  faulty,  it was  common to have    glitches w/automated  configurations

Size change - Boot screen framebuffer mode gets changed @desktop activation
xorg.conf is used to set desired modeline/s

Please try commands
scanpci (locates device bus)
dmesg |grep MATROX  (VL found card)
xrandr   (see what modes can be used)

Read  /var/log/Xorg.O/.log ,     Xorg.O.errors.log

[furydragon]

Similar problem can be if You use incorrect console font for your locale. Try change console font (for example, modify /etc/rc.d/rc.font scrip). List of font You can see in /usr/share/fonts directory.
Other reason is incorrect x driver (see above). Try boot in pure text mode (select such menu in boot loader on booting).

[Colonel Panic]

Thanks for your replies. I think I'll try rm-r's suggesting of editing lilo.conf first (it's easiest) and only if that doesn't work try editing the rc.font file (easy to make a mistake with that one IMO) and looking at the outputs of scanpci etc.

Best,

CP .

[furydragon]

After manual changes in lilo.conf you should reinstall lilo.
Lucky!

[Colonel Panic]

Thanks again. I've just printed this thread off for reference.

Best,

CP .

[Colonel Panic]

Here are the results of my scanpci test;

pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x8086 device 0x1130
 Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub

pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x8086 device 0x244e
 Intel Corporation 82801 PCI Bridge

pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x8086 device 0x2440
 Intel Corporation 82801BA ISA Bridge (LPC)

pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x8086 device 0x244b
 Intel Corporation 82801BA IDE U100 Controller

pci bus 0x0000 cardnum 0x1f function 0x04: vendor 0x8086 device 0x2444
 Intel Corporation 82801BA/BAM USB Controller #1

pci bus 0x0000 cardnum 0x1f function 0x05: vendor 0x8086 device 0x2445
 Intel Corporation 82801BA/BAM AC'97 Audio Controller

pci bus 0x0002 cardnum 0x08 function 0x00: vendor 0x8086 device 0x2449
 Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller

pci bus 0x0002 cardnum 0x09 function 0x00: vendor 0x5333 device 0x5631
 S3 Inc. 86c325 [ViRGE]

Thanks in advance,

CP .

[rm-r]

http://www.s3graphics.com/en/drivers/legacy_software_archive.aspx

Above was for Xf86 - may no longer work
 
Please see content of (dmesg)  look for s3 or virge

(Didn't vesa as driver work in xorg.conf ?)

[Colonel Panic]

Thanks for replying.

Dmesg came up blank for some reason - trying to pipe it into a text file resulted in a file of 0 bytes, but I'll try again when I'm on my own machine.

I'll download that driver file and see if it works.

Best,

CP .

[fogpipe]

Hi. I'm one of your "vintage machine" users, having a computer with a Pentium III Coppermine (866 MHz) processor, a 30 GB hard drive and 512 MB of Ram.. I've recently downloaded and installed Vector 7.0 Beta, and for the most part it works very well.

However,  I've recently been using an old Matrox Millennium 3D card (4MB of video RAM) and I've encountered a problem with this. It works pretty well as long as I'm in X Windows mode, but when I switch to the bare console the edges of the screen "overflow" so that I can't see, for example, either side of the file listings in Midnight Commander properly, or the whole of the word "root" in the standard "root: #" command prompt.

I've tried changing the screen mode from 80x25 to something with a different number of columns, but to no avail; it boots into a console of 28 lines depth and 80 columns wide  (but with overhang) whatever I set.

Has anyone got any idea of what could be wrong, and how it could be fixed short of getting another video card?

Thanks in advance,

Colonel Panic .

P.S. I should perhaps point out that this is not just a problem I have in Vector 7 Beta, but it also happens in other Linux distros I've tried as well as in previous versions of Vector. Also, the "overhang" I'm talking about doesn't happen when the computer is actually booting up; it only manifests when the computer has actually finished booting.

This is a result of framebuffer console support. The only way i have found to get around it is to recompile the kernel with no framebuffer console support. Im using an older machine temporarily myself and x runs smoother with out frame buffer consoles on the other tty's and all framebuffer consoles do is take up memory that could better be used else where. Imo framebuffer consoles are a terrible idea, especially to be enabled by default, if you are having video problems, why make your route to a solution that much more dependent on normal video function?  So try a recompile and leave out the framebuffer consoles. In the kernel compile menu you will find that option under Devices Drivers->Graphics Support->Console Display Driver Support->Framebuffer Console Support. Just say no

[rm-r]

F-P

Sorry - such behaviour is often a result of Distro -specific MIS application of frame buffers:

F/buffer support  has existed in Kernels from distant beginnings

All boils down to chipset driver firmware -vs Distro probe methods
That is why/when NUMEROUS available  boot_line_options may be appended
 
Only recently has it been been Kernel.org  recommendation ~ when using proprietary drivers - disable F/buffers

The kernel config make file has toggled explanations of options

TTY's  (true console mode) bad concept  mem_ alloc is (niceness) asymetrically applied via forked process/es

(scheduler)

Buffers are "padded"  Ram resources  for expected  reads - then I.O. used
Mem is constantly allocated,     then freed

OEM Chipset firmware determines whether kernel may re-route or reserve GPU  MEM ranges   
(examine dmesg MEM mapping

Exceptions > real time  scheduling

Practical uses -  examine "top" content  ~ Set trace points while coding ~ SEE ABI events
 
Perhaps YOU do not use console mode - most power users do

> Including monitoring install procedures

Obfuscation yes  -  only    excuse, clarification

[fogpipe]

F-P

Sorry - such behaviour is often a result of Distro -specific MIS application of frame buffers:

F/buffer support  has existed in Kernels from distant beginnings

All boils down to chipset driver firmware -vs Distro probe methods
That is why/when NUMEROUS available  boot_line_options may be appended
 
Only recently has it been been Kernel.org  recommendation ~ when using proprietary drivers - disable F/buffers

The kernel config make file has toggled explanations of options

TTY's  (true console mode) bad concept  mem_ alloc is (niceness) asymetrically applied via forked process/es

(scheduler)

Buffers are "padded"  Ram resources  for expected  reads - then I.O. used
Mem is constantly allocated,     then freed

OEM Chipset firmware determines whether kernel may re-route or reserve GPU  MEM ranges   
(examine dmesg MEM mapping

Exceptions > real time  scheduling

Practical uses -  examine "top" content  ~ Set trace points while coding ~ SEE ABI events
 
Perhaps YOU do not use console mode - most power users do

> Including monitoring install procedures

Obfuscation yes  -  only    excuse, clarification

I have tried a few distros recently and all of them had a problem displaying framebuffer consoles correctly with the video hardware im using.
It should be a choice not a default. Its tough to fix something when you have to keep typing "clear" every few seconds. I dont care about being a power user, i care about what works with the circumstances in play