OK - solvable by getfont/setfont pair as you described lower.
> > Disadvantages of the current solution:
> > * You must load some disk font when setting better video mode
> > (no chance of leaving the old BIOS-related font).
>
> Same thing when implemented in the kernel: the old stored font will need to
> be replaced as well. It's not because it is "hidden" in the kernel that it
> does not happen.
dtto.
> SVGATextMode could be adapted to read the old font before enabling HSText
> and restore if afterwards, which would also allow you to skip font-loading.
> The change is trivial.
OK - already done in that patch i posted.
> > * No elegant method of loading of custom fonts.
>
> How so? What is "elegant"? SVGATextMode allows you to select a font for each
> possible character size in the /etc/TextConfig file.
>
> SVGATextMode relies on setfont to load fonts, so if the font-loading is not
> elegant, it's because setfont isn't elegant :-)
setfont IS elegant. What I want is the ability to change fonts during normal
later usage of machine as there are some problems with Czech Republic accented
encoding letters (this is now solved by using mapping - mj@ucw.cz). But
there may be always user needs and wishes to dynamically change fonts once and
later during system run without permanently changing the contents of
/etc/TextConfig.
> > This patch's solution:
> > Kernel checks for S3 card during boot and by internal getfont/setfont
> > pair sets up the high speed mode with leaving the current font unchanged.
>
> My personal opinion is that there may be more disadvantages than advantages
> to this. You're the first to tell me that the current SVGATextMode
> implementation is not what you want. That doesn't mean noone agrees with
OK. I'm proud to be that one. :-))
> you, but everyone who writes free software will tell you that people almost
> never tell you when your program works well, while they are much more
> inclined to complain if it doesn't work as expected...
OK. Acknowledged.
> Anyway, S3 may choose to drop "high-speed textmode" from their future chips
> at any moment in time, and then the Linux kernel may actually cause your
> text screen to go bungee-jumping with a non-elastic rope.
Yes, but this support should be configurable and mostly it wasn't meant
to go to the standard kernel anyway. And under Linux you SHOULD know what
are you patching.
> Actually, the trend nowadays is downward for textmodes: all those new cards
> using synchronous memories have very low textmode performance (due to the
> high latency of typical synchronous memories compared to the old DRAM, which
> is very bad for the hectic memory-access method used by textmodes.
Hmm... :-( Fortunately these cards are becoming faster so that the FBCon
solution wouldn't be much slower that the traditional textmode on current cards.
> Anyway, I am not questionning the validity of your patch (can't test it,
> since I have neither an S3 card nor am I running any of the 2.1.xxx
> kernels).
>
> Koen.
Lace
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html