Problems with text display in VL console

[rm-r]

FP

2cents =  02.003 U.S >  Why not blame Intel -not Distros ~ (then address practicalities I.E. change H/ware or cope)

http://www.digitalhermit.com/linux/hiresconsole.html

[Colonel Panic]

Thanks for the info about framebuffer support, and disabling it when you recompile the kernel.

I quite like that idea at the moment, though a quick google on "framebuffer" came up with this useful article, which has a section for Matrox Millennium users like myself;

http://www.digitalhermit.com/linux/hiresconsole.html

So I may try that instead If I get brave enough to attempt a kernel rebuild, which I haven't yet in over 5 years of using Linux!).

Cheers,

CP .

[fogpipe]

FP

2cents =  02.003 U.S >  Why not blame Intel -not Distros ~ (then address practicalities I.E. change H/ware or cope)

http://www.digitalhermit.com/linux/hiresconsole.html

Why spend money on hardware i dont need if there is a simple straightforward solution that involves no money and little time?
 And it isnt jsut intel, i have used video hardware on other machines, mostly older ones, that didnt display the framebuffer console correctly. Even on a machine with hardware resources to spare, framebuffer consoles are sometimes visibly slower, it would be much better to be offered the choice. I realize tho that framebuffer support is compiled in (iirc) and not a module, so it would add the over head of another kernel to the install media, and that its about how it looks and not functionality.

[fogpipe]

So I may try that instead If I get brave enough to attempt a kernel rebuild, which I haven't yet in over 5 years of using Linux!).

Go for it dude

As long as you remember to append a version string to the kernel so that the module installer doesnt put the modules in the same dir in /lib/modules that was installed by the distro and remember to edit your lilo config appropriately to add the new kernel you just built, its pretty safe. The worst that can happen is that you build a kernel that wont boot and you still have the original as a fallback.

This is my original vector kernel from lilo.conf:

image = /boot/vmlinuz
root = /dev/hda5
label = linux-vl6r2
append = "2 "
read-only

This is the one i built with some environment specific tweaks:

image = /boot/vmlinuz-2.6.27.12bo
root = /dev/hda5
label = Bo-vl6
append = " "
read-only

Notice the difference in names, that way there is no confusion. Append the version of the kernel you just built to the System.map and config files as well, ie System.map-2.6.27.12bo and config-2.6.27.12bo and you will be good to go and still have the original vanilla kernel as a back up. Dont forget to back up your lilo.conf just in case.

[rm-r]

Colonel Panic

A suggestion : Before re-compiling kernel, examine your config make file

Look for the frame buffer  option - note if it is  set

 All those neat tips to re-compile did not mention  *most  important*  if wishing to use alternate versions 
(@ make command string)

Addit: http://www.x.org/archive/X11R6.8.0/doc/fbdev.4.html

[fogpipe]

Actually, this is the doc for the kernel module, called fbcon : http://www.mjmwired.net/kernel/Documentation/fb/fbcon.txt and its some interesting reading. Apparently there is a way to disable the framebuffer console. Check out the fbcon=map:<0123> option.

EDIT: I guess i should check out the docs before shooting my mouth off I wish i could say it will be the last time i do it
Anyway, i just checked and i dont have a kernel running on my machine that has an fbcon module compiled for it. If anybody tries this could you post the results here?
my guess is that the way you would use it would be to put a file in /etc/modprobe.d named "fbcon" and containing the single line "options fbcon=map:1" .

[fogpipe]

 All those neat tips to re-compile did not mention  *most  important*  if wishing to use alternate versions 
(@ make command string)

I was assuming he could get the basics from a howto, i beleive there is one up at kernel.org. I just wanted to give him some tips on not over writing his current kernel

[rm-r]

F-P

There's nothing wrong to affering alternate solutions
 I have no objections to any opposing views ~ *Until*    they are off-handledly stated as "proof-positive"

Merely saying

And it isnt jsut intel, i have used video hardware on other machines,
 mostly older ones, that didnt display the framebuffer console correctly.

   Obfuscations entered: (No resources to  qualify WHY frame buffers are evil)

= Does not appear to be substantiated by Forum/Web blogs complaints Re glitches in console displays

Nor does kernel re-compile tips address user's comfort-level, pre -requisites to employ methods

Code:

If I get brave enough to attempt a kernel rebuild, which I haven't yet in over 5 years of using Linux!)

To date, COLONEL - we have not been informed of VL version (does kernel sources exist)
~ Have not seen error logs, xorg.conf content

Conversely,

Code:

A frame buffer device is a memory device like /dev/mem and
it has the same features. You can read it, write it, seek to some location in
it and mmap() it (the main usage). The difference is just that the memory that
appears in the special file is not the whole memory, but the frame buffer of some video hardware

Please see (/dev/fb_nx) ~ /usr/src/linux_nx/documentation

NOTE: ~ Reserved vs re-mapable - SIZE (very small - only use is for text display/colours)
If/when reserved - unavailable for total GPU Mem

Has NO relation to system RAM (GPU firmware resource only)

Back to basics - which method appears least demanding_ VL default tools,
vs ~ CLI vargaries, danger of in-advertant  O/system corruption

Worst case scenario - system becomes un-bootable, NO  rescue media to access, repair
OR ~ CLI/media tools ARE available, uncertaintity how to apply

Consider how troublesome IS present glitch ~ rather than   using  console mode:
~  Open a GUI terminal- emulator

You (presently) have no problems in desktop mode - why risk failed kernel re-compile,
add complexities of alternate kernels - become over-whelmed w/new problems self-invoked ?

vs (Save user customizations?)  - Install latest Beta - see if any previous bug is gone

NTIM _ So called "power-users" (hate terms "Guru/NuB")  research, ensure resources are available prior to
empirical testings

If ever unsure of present capability to recover gracefully - that may be time to contemplate:

"If it ain't broke - don't *fix* it 
 

[rm-r]

F-P

These aside_ academia views are complicating read-ability

Before we invoke Mod intervention please note:
Repetitive references to modules overlook ~ some needs are not to be modularized

I.E.  in-use root_fsystems, virtual_mem,   X-windowing

[fogpipe]

I couldnt get the fbcon thing to work because the only kernel i have with framebuffer support enabled is the new VL beta and according to /proc/config.gz framebuffer support is compiled into the kernel. I took a look at man fbset and couldnt get that to work, but i did find this:
http://bkhome.org/blog/?viewDetailed=01706
Apparently framebuffer console problems are common enough and i am about to reboot and try the solution in the above url.


EDIT: SUCCESS! passing the kernel "video=640x480" gives a readable console that looks just like the default vga, and the screen and monitor edges match. YAY!

EDIT: This is totally cool. Thanks for starting the thread CP!

[rm-r]

Yes , trust B.K (& community)  to come up w/"different" approaches
---------------------------------------------------------------------------------------------------------------------------------------------------------

F-P ~Glad it worked for you - however, Barry's work-around   is not a panacea - it relies on module * fbcon* to be present

Most Distros use fbdev

Code:

there is not a return to our old and familiar VGA text mode, instead it stays in framebuffer console mode, which has the small text.

Which does not explain how that

Code:

video=640x480

differs from use of *VGA =ask*  ~then  apply

You really should learn how VESA standards apply to  chipset-firmware &/or  OEM  non-conformity to stipulations 
----------------------------------------------------------------------------------------------------------------------------------------------------------
His Tmp solution (which he is not happy with) relates to use of fbcon module

NOTE ~ That addressed only PUPPY community,  reports of  "small text displayed"  ~ NOT weird behaviour @ bootup,  or text out of view

Further,  since when is Nouveau (Xorg driver) a VID  hardware device ?

Did you fail to read bug reports -  it is an OEM firmware policy now NOT kernel or Xorg

[Colonel Panic]

A quick update; I solved this for the time being by installing Vector 5.8 Standard. For some reason it doesn't have the framebuffer console display problem I've described here, and it runs Softmaker Office 2008 so is useful as a home / office distro.

It might not be as secure for most people as a later Vector release would be so I couldn't recommend it for others, but I don't have a home internet connection at the moment so this doesn't matter much in my case.

Cheers,

CP .