First, I was talking about the way keystrokes get mapped to keysyms that
get sent to the tty.

Here we need a way to distinguish the key-to-char-mapping depending on
your favorite locale. This mapping could even be UTF-8 giving full 16-bit
unicode over 8-bit ttys (Fonts are another story ...).

With  Lennart Augustssons changes it is impossible to modify the current
keyboard map, so this needs to be changed anyway.

On Mon, Apr 01, 2002 at 05:49:04PM +0400, Valeriy E. Ushakov wrote:
> On Mon, Apr 01, 2002 at 13:40:35 +0200, Juergen Hannken-Illjes wrote:
> 
> > With Lennart Augustsson addition of cyrillic keysymbols (which is totally
> > wrong this way) we need a method to pass non-iso8851-1 keystrokes through
> > wscons.
> > 
> > I propose two ioctl's to get/set a codeset on a screen. The codesets map
> > keysymbols to 8-bit characters.
> 
> I don't like the whole wscons/unicode business in its current shape.
> It's absolutely undocumented and its design goals are not clear.  I
> tried to brought up this question several times but got absolutely no
> response.
> 
> E.g. what are the clients of this kbd codeset API other than the
> kernel itself?  Do you expect 1) several programs 2) working with raw
> ws events 3) running simultaneously and 4) using different locales
> internally?
> 
> The 1-4 above hold for X11, so in X11 the keysym design is justified.
> But wscons is a terminal emulator, I just don't see any need for such
> complexity of (de facto) internal interfaces.
> 
> Exisiting usage of unicode in wsfont stuff also seems to me like an
> overkill.  First, note that wscons doesn't provide for multicharset
> output, e.g. I cannot display a mixture of cyrillic and latin-1 text
> on a single wsscreen, so I think it's not a big stretch to say that
> wscons emulates something that is, conceptually, a terminal like vt220
> with downloadable fonts.
> 
> Consider a real hardware vt220 with loadable fonts.  I can load a
> koi8-r font or ISO8859-5 font or latin-N font and vt220 doesn't care,
> it will just happily pass on G1 chars and let the user take care that
> the loaded font matches his locale.  This is a very well understood
> model that's been around for ages.
> 
> Now why this unicode stuff is in then?  From reading the source the
> only usage I can see is to remap line drawing chars.  As long as I
> don't use line drawing chars, I can load a koi8-r font into wscons
> (w/out specifying any encoding, in fact lying to it that the font is
> iso) and use it happily b/c the vt100 emulation in wscons is just like
> a real vt, it doesn't give a damn about G1 chars, it just passes them
> on and displays them in whatever font is loaded.
> 
> So for this simple terminal emulation why do we need a layer of
> unnecessary complexity?  The problem with line drawing chars can be
> solved without throwing all the unicode at it.
> 
> SY, Uwe
> -- 
> uwe@ptc.spbu.ru                         |       Zu Grunde kommen
> http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)