Prev: Upgrading OO.o, right hand doesn't know what left hand is doing
Next: Debian per Packard Bell
From: Stephen Powell on 22 Jan 2010 11:10
On 2010-01-22 at 09:00:54 -0500, Javier Barroso wrote:
> Seem like gfxpayload is the substitute, but now I can't find where is the
> doc (it doesn't appear in kernel-parameters.txt).

The "vga" kernel option is a strange option. It's really more of
a bootloader option than a kernel option. The bootloader itself has to have
support for it. The actual change of video mode is done by means of a
video BIOS call. This is an old-fashioned DOS-style interrupt call,
which must be done in real mode. I believe the bootloader itself makes the call,
while it is still running in real mode. The bootloader switches to protected
mode prior to passing control to the kernel. Somehow, the kernel is told
what the video mode is, so that it can allocate the proper amount of memory
for a virtual terminal buffer, but I don't believe that the kernel itself
actually makes the video BIOS call. That's the way it worked under lilo and grub1
anyway. This is for text-mode virtual consoles.

I'm really going out on a limb when I talk about grub2, since I only used
it for a very short time, but I seem to remember that gfxpayload sets the
video mode for grub itself. I don't think it applies to the kernel proper.
The doc for grub2, such as it is, is at
http://www.gnu.org/software/grub/grub-2.en.html. I gave up on grub2
rather quickly and went back to lilo when I couldn't get the vga option
to work; so I know very little about it.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Arthur Machlas on 22 Jan 2010 12:10
On Fri, Jan 22, 2010 at 10:03 AM, Stephen Powell <zlinuxman(a)wowway.com>wrote:

> On 2010-01-22 at 09:00:54 -0500, Javier Barroso wrote:
> > Seem like gfxpayload is the substitute, but now I can't find where is the
> > doc (it doesn't appear in kernel-parameters.txt).
>
> I'm really going out on a limb when I talk about grub2, since I only used
> it for a very short time, but I seem to remember that gfxpayload sets the
> video mode for grub itself. I don't think it applies to the kernel proper.
> The doc for grub2, such as it is, is at
> http://www.gnu.org/software/grub/grub-2.en.html. I gave up on grub2
> rather quickly and went back to lilo when I couldn't get the vga option
> to work; so I know very little about it.
>
>
set gfxpayload=keep will tell Grub2 to hand off the graphics settings to the
kernel, which if configured properly will carry them forward. There are some
other settings to tweak as well, insmod vbe and whatnot in the appropriate
file, but that's about the gist of it. The nice thing is it makes for very
smooth transitions when switching from terminal to x, as the display
settings (if correctly configured) are already applied, thus, no ugly
flashing of the screen and delay.

Best,
Arthur
From: Chris Jones on 22 Jan 2010 16:00
On Fri, Jan 22, 2010 at 01:08:23PM EST, Stephen Powell wrote:

[..]

> So then this is designed to work with framebuffer graphics mode
> virtual consoles, right? That wouldn't help me. I prefer the
> traditional hardware text mode virtual consoles.

Just curious, but what's wrong with using a framebuffer console?

CJ







--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Stephen Powell on 22 Jan 2010 16:50
On 2010-01-22 at 15:50:02 -0500, Chris Jones wrote:
> On Fri, Jan 22, 2010 at 01:08:23PM EST, Stephen Powell wrote:
> > So then this is designed to work with framebuffer graphics mode
> > virtual consoles, right? That wouldn't help me. I prefer the
> > traditional hardware text mode virtual consoles.
>
> Just curious, but what's wrong with using a framebuffer console?

There's nothing "wrong" with using a framebuffer virtual console,
and there's nothing "right" about using a traditional hardware
text mode virtual console. It's a matter of preference.

I prefer a hardware text mode virtual console for a number of
reasons, but one of them is that it performs better, particularly
on the ancient under-powered hardware that I tend to use!
For example, screen scrolling is quite snappy on a text mode
virtual console, but on a framebuffer virtual console it can
be sluggish, depending on processor speed. Besides, if I am editing
text, doesn't it make sense to use text mode? Isn't that what
text mode was created to do? I'm not against GUI interfaces,
per se. They have their uses. And I do use them. But if
I'm going to be doing some serious text editing, I always
switch to a text mode virtual console and do my editing there.

I don't try to convert others to my way of thinking. If they
want to use a GUI interface for everything, that's fine with
me. But I do resent it when the movers and shakers try to
eliminate every last vestige of text mode from the system.
Text mode is simply the fastest and most efficient way to
edit and peruse text. Surprise, surprise! In fact, I support
quite a number of machines that don't even have X installed.
Why use a frame buffer virtual console under those conditions?
All it does is consume resources and slow things down.


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Chris Jones on 23 Jan 2010 03:40
On Sat, Jan 23, 2010 at 01:15:39AM EST, Chris Jones wrote:

[..]

> I the above question the bizarre joke, or was this meant as a reply to a
> different post?

s/I the above/Is the above/


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Upgrading OO.o, right hand doesn't know what left hand is doing
Next: Debian per Packard Bell