>> I'd prefer this order since there are going to be the unforseen
>> times when the card may be capable of it but the monitor isn't.
>> If we default to plain vanilla text mode and do everything else as
>> an option, the suprises will be minimised.
===8<=== CUT ===>8===
> Great idea! But how do you find out what (if anything) the card
> supports? Without crashing it (and the system), without ugly
> flashing, and without 5Mb of code in the
> kernel/bootloader/whatever? Just doing text mode properly will cost
> you at least half a Mb...
{Shrug} For some reason, when I select a Linux kernel image from LILO
that has "vga=ask" in the relevant block, I get a list of supported
text modes. I would presume that the addition of a list of graphics
modes for use in this context would be provided the same way...but
then, I'm only a naive systems programmer, not somebody likely to know
things like that...
> Look, that Sun can put up a pretty color logo (SPARC Linux does it
> too, BTW) just says that Sun hardware is the same in all machines,
> you can depend on the same graphics commands for all. This is
> definitely *false* for PCs (there is _one_ Xsun, and 13
> XFree86-<whatever> X servers for PC... and that does just cover the
> ones that can be shipped in source code; at the very least SuSE has
> some more that can't).
Perhaps you can tell me what you're trying to say with the above
paragraph, as it appears to be completely pointless to me...
On the other hand, perhaps I'd better state clearly how I currently
see the whole idea of boot logo's being implemented. Hopefully, the
following will clear this up...
As I see it, there are the following cases to consider:
1. A system with Linux installed on the hard disk, and booting from
the hard disk via a boot loader (such as LILO, MILO, LOADLIN or
the like) that knows about boot images.
The basic assumption here is that the person who installed Linux
knows what sort of graphics card and monitor is in the system it
was installed on, and has verified that a given mode is compatible
with both. I would therefore expect to discover that lilo.conf (or
the equivalent for the other boot loaders) included the following
lines for the image in question:
bootimg=/boot/bootimg.gif
bootmode=193
One assumption hidden in there is that the hardware now is the
same as when lilo.conf was last modified, and there would have to
be a means of booting if changes were made that rendered the old
settings incompatible. My suggestion for that would be a parameter
typed by the user on the selection line, such that (for example)
the following would tell LILO to ignore those two options:
LILO: linux noimg
2. A system with Linux installed, that boots off a removable disk
that can be used with several different machines with different
hardware, but using a boot loader such as LILO.
There are two obvious ways of dealing with this case, namely:
A. Have multiple image selection blocks defined in lilo.conf
and select the one appropriate to the particular system.
B. Have an autoprobe sequence in the kernel that looks for the
mode most likely to be supported, but allow it to be told
not to probe but to use a specified mode on the command line
similar to how many current kernel modules work.
There are probably others, but I'm not aware of them.
3. An installation set for Linux, as could be provided by RedHat,
Slackware, Caldera and the like.
Since this will by its nature be used with a large variety of
different systems, many with incompatible hardware types, the
only real options are:
A. Some sort of autoprobe sequence that can be overridden at
startup, similar to (2.B) above.
B. An autoprobe to detect the available modes, then a menu on
which the user can select the one to use.
I've probably missed some scenario, so please add to this list as
appropriate...
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu