VectorLinux
November 28, 2014, 12:20:01 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1] 2
  Print  
Author Topic: Problems with text display in VL console  (Read 8656 times)
Colonel Panic
Vectorian
****
Posts: 526


« on: February 26, 2011, 01:08:33 am »

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.
« Last Edit: February 26, 2011, 01:11:05 am by Colonel Panic » Logged
nightflier
Administrator
Vectorian
*****
Posts: 4031



« Reply #1 on: February 26, 2011, 02:29:07 am »

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?
Logged
Colonel Panic
Vectorian
****
Posts: 526


« Reply #2 on: February 26, 2011, 03:54:49 am »

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.
« Last Edit: February 26, 2011, 04:00:18 am by Colonel Panic » Logged
rm-r
DoucheBag
Vectorite
***
Posts: 115


« Reply #3 on: February 26, 2011, 04:01:03 am »

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
Logged

"Problems are seldom resolved by thinking in the same manner they were created"

"What is viewed is not important - That which is seen is"
rm-r
DoucheBag
Vectorite
***
Posts: 115


« Reply #4 on: February 26, 2011, 10:39:35 am »

Colonel

Quote
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  Angry  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 ,   Huh  Xorg.O.errors.log
Logged

"Problems are seldom resolved by thinking in the same manner they were created"

"What is viewed is not important - That which is seen is"
furydragon
Member
*
Posts: 26


« Reply #5 on: February 27, 2011, 01:34:10 am »

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).
Logged
Colonel Panic
Vectorian
****
Posts: 526


« Reply #6 on: February 27, 2011, 02:41:57 am »

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 .
Logged
furydragon
Member
*
Posts: 26


« Reply #7 on: March 04, 2011, 10:50:55 am »

After manual changes in lilo.conf you should reinstall lilo.
Lucky!
Logged
Colonel Panic
Vectorian
****
Posts: 526


« Reply #8 on: March 10, 2011, 12:07:43 am »

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

Best,

CP .
Logged
Colonel Panic
Vectorian
****
Posts: 526


« Reply #9 on: March 10, 2011, 10:57:06 pm »

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 .
« Last Edit: March 11, 2011, 01:01:51 am by Colonel Panic » Logged
rm-r
DoucheBag
Vectorite
***
Posts: 115


« Reply #10 on: March 11, 2011, 12:00:59 am »

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 ?)
Logged

"Problems are seldom resolved by thinking in the same manner they were created"

"What is viewed is not important - That which is seen is"
Colonel Panic
Vectorian
****
Posts: 526


« Reply #11 on: March 11, 2011, 01:01:07 am »

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 .
« Last Edit: March 11, 2011, 01:02:41 am by Colonel Panic » Logged
fogpipe
Vectorite
***
Posts: 105


« Reply #12 on: March 11, 2011, 07:22:04 pm »

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 Smiley
Logged
rm-r
DoucheBag
Vectorite
***
Posts: 115


« Reply #13 on: March 11, 2011, 09:54:37 pm »

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  Roll Eyes 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,  Cool   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  Embarrassed  excuse, clarification
Logged

"Problems are seldom resolved by thinking in the same manner they were created"

"What is viewed is not important - That which is seen is"
fogpipe
Vectorite
***
Posts: 105


« Reply #14 on: March 11, 2011, 10:26:41 pm »

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  Roll Eyes 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,  Cool   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  Embarrassed  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 Smiley
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!