Re: Second stage console problem
On Fri, 2003-11-14 at 06:21, Miroslav Kure wrote:
> On Thu, Nov 13, 2003 at 05:05:43PM -0500, Joey Hess wrote:
> > Kenshi Muto wrote:
> > > How do you think about following flowchart, Joey?
> > >
> > > n
> > > check tty -> serial. 2nd stage as current LANG (*1)
> > > | y
> > > v y
> > > check fb0(*2) -> run bogl-term as LANG(*3)
> > > | n
> > > v y
> > > acceptable LANG without bogl-bterm?(*4) -> 2nd stage as LANG
> > > | n
> > > v
> > > cancel LANG (use English)
> > > |
> > > v
> > > 2nd stage
> > >
> > > *1: If you want to install in serial console/non-FB machine, you can
> > > use only English installer, it means LANG of 2nd stage is always
> > > English (C).
> > > *2: Current termwrap looks don't implement yet.
> > > *3: Current termwrap looks don't implement yet.
> > > *4: Current termwrap looks implement partly? I think this needs
> > > various people's help.
> >
> > Yep, that sounds right.
>
> Yet there is the issue with latin-* languages, who don't need
> special terminal, but only need to set correct font in the
> console-tools package.
> E.g. accented characters in iso-8859-2 (Czech, Slovak, maybe
> others) won't display correctly until you set lat2 console font,
> which makes base-config almost unreadable.
>
> Regards,
> Miroslav Kure
Ok,
Two things to take note of:
(1) I'm implementing a default font for linux console in console-data
that will provide Latin, Hebrew, Cyrillic. I can detect and change that
based on default locale if necessary - setting eg an iso02 based one.
However, there is a catch: if you set a vesa screen mode, e.g. to set a
font or console screen size, then setting a font will undo that. So I
have to detect a vesa mode and _not_ set font in that case, but leave it
to the user. I'm detecting VESA modes by looking for "vga=" on
/proc/cmdline; if a framebuffer is set by default here, the font will
not be set.
(This need not be a problem for base-config, as it can use bogl and load
a framebuffer after boot. But help will be needed by various arch people
to debug this).
(2) Important: There is a bug in the linux kernel API that makes
combining characters (accents) at the keyboard effectively impossible in
UTF-8 mode: (the API only allows a _char_ for the result of a diacritic
-type key: hence compose chars don't work properly in UTF-8 modes).
I don't think bogl does anything smart about this; it means that
_at_the_console_ entering accents in UTF-8 locales is broken.
While this does not affect d-i at the moment (no dialogs that want
arbitrary text), it means most users will not want UTF-8 locales on the
console.
Regards,
Alastair McKinstry
>
Reply to: