On 2013-02-11 12:41 (GMT-0800) Linda Walsh composed:
The main complaint was there was no way to shut off it's flipping into frame buffer mode.
By doing so, it flipped into a mode that the card could only support a 1/3 height set of ~25 lines at the top of the screen. Nothing I did would cause it to go back.
At this point I'd really like to know how to turn off the flip into FB mode, vs. disabling support for my chipset in a special kernel build.
What's your current /proc/cmdline content? stty -a output? Is all viewable area currently in use on the vttys?
The speed is the least of the worries. Most users wouldn't know the difference between hw-assisted scrolling and framebuffer text that is done with memmove's -- a bit at a time to make it scroll smoothly -- but is harder to read on an LCD -- maybe the persistence effect.
I can see the text and make out words as they zip by on a text boot but not on a framebuffer boot.
Also there is no loss of screen picture as it flips from one mode to the other in the middle of the boot when it stays in text mode (in the few times it came up in 1/3rd tall framebuff mode).
The modes I'm aware of are standard BIOS modes, extended BIOS modes that may or may not conform to VESA standards, and framefuffer modes, so it may be that we have context and/or terminology differences in this thread. So, I'm going to stop using the word "framebuffer". I've seen two general cases where an initial mode worked as expected initially, followed by a mode switch that caused row count and/or viewable area on a vtty to become fouled: 1-Old Intel chips with no VESA support, but with proprietary text VBIOS extension modes, IIRC 132x25, 132x43, 132x50 & 132x60. 2-Matrox chips manufactured last century (Millenium, G200, G400, G450), which originally had poor or no VESA support, but improved VESA with later available VBIOS upgrades. With both, using most distros I've ever used, except for *buntus, booting with such cmdline parameters as vga=0x121 or vga=0x30A supported by BIOS, but partially or none by VESA, causes behavior you described, changing from a competent mode to an apparently incompetent one, with improper row and/or column count to fit the font used to the available screen space. I found two solutions to this that work at least for both the i810 and the Matrox G400. For the latter when using openSUSE and most distros I've used, vga=0x30A on cmdline only works as a normal mortal would expect if one of two things are done: 1: change the 16 CONSOLE_FONT in /etc/sysconfig/console to an 8, or 2: disable user-space console font setting such as described in https://bugzilla.kernel.org/show_bug.cgi?id=7513#c7 Either of these methods I would expect to be valid solutions for your desire to maintain the mode and fonts used on boot and on init initially all the way through init and on all vtty logins. For me on G400 currently with vga=0x30A on cmdline and the standard configuration of the two above items, stty -a shows 21 rows, and only about 55-60% of the available screen height used. Switching CONSOLE_FONT from the default 16 to an 8 changes stty -a output to 43 rows using about 80% of the screen height. All size 9 or 10 fonts I tried did worse. Upthread you asked why the suggestion to try a PCI video card. I answered, but failed to include mention that this discussion is all about behavior with gfxchips that KMS does not support. With a PCI video card featuring an ATI or NVidia chip, or a few others less common, KMS should be able to produce a framebuffer mode (via video= on cmdline, not vga=) to please you, something that may truly be impossible as long as you're using Matrox and neither kernel developers nor Matrox provide KMS support for Matrox gfxchips in maintained kernels. This all assumes also use of Lilo or Grub Legacy. Grub2 may produce different complications with its deprecation of vga= and introduction of gfxpayload as its replacement. AFAICT, systemd has nothing to do with any of this. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org