Thank you for your replies.
I think I missed one point in my question. When I was referring to the "linux console",
what I actually meant was the Linux serial console (/dev/ttySxx) device not the VGA console. Sorry!
The discussion threads that Simon pointed out was centred around the complexity of implementing
full fleged support for Unicode rendering on the VGA console, if I am correct.
When a terminal emulator is connected to the serial console how does the character generation
take place:
a) Keyboard combination pressed by user generates the unique Unicode code point for
a particular character, which is received by the serial driver which is encoded into UTF-8
and passed to the stdin of the foreground process (as UTF-8) ?
b) The terminal emulator generates the UTF-8 sequence corresponding to the character
pressed by the user ?
Also, do we have keyboards that are specific to locales ? i.e They permit input of characters
specific to a language say "chinese" only ? or do all keyboards permit input of US-ASCII characters.
Or is it that the key-combinations are mapped to a Unicode code point by the terminal
emulator which get sent to the serial console ?
Thanks, Shesh.
From: Markus Kuhn <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Linux kernel 2.4.20 & internationalization Date: Wed, 16 Mar 2005 10:59:31 +0000
"Sheshadrivasan B" wrote on 2005-03-16 07:21 UTC: > I need to know if Linux kernel 2.4.20 supports internationalization.
There is almost nothing in terms of i18n and very little in terms of character encodings that is of concern to the kernel. Practically all this happens at the library level and above. In particular, the kernel remains ignorant of the locale settings chosen by the user.
Noteworthy exceptions:
- The "cooked mode" in the tty driver needs to know when UTF-8 is used to handle the delete/erase key correctly. Support for this was added in an early 2.6 kernel and UTF-8 remains the only multi-byte character set the kernel is aware of.
- There has been rather primitive UTF-8 support (ISO 10646 Level 1 with up to
512 glyphs) in the text-mode console driver of Linux for almost a decade.
- There have been filename encoding conversion facilities in the VFAT and NTFS
drivers for many years.
All of these are issues that the average user of a graphical Linux desktop is hardly ever going to encounter in practice.
Nevertheless, the Linux distributions that are particularly renown for their good internationalization support are all using the 2.6 kernel today and they all use UTF-8 locales by default. If you are using an older 2.4-kernel-based distribution, the libraries and tool that come with it are very likely to be at least a year behind the state of the art in i18n matters.
Markus
-- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
-- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
