> Also, I think that console-keyboard drivers may be divided to 2 versions, > with kernel build option: > > the simple, with fixed 8bit codepage, unused legacy things like VT100 graphics > removed > (for people who dont'n need i18n or work not so much in console) > > and the sophisticated, full-functional and well internationalized.
Yes, I think this is the way to go. I imagine we will meet a lot of resistance if we try to add heavyweight Unicode stuff into the existing console. The heavyweight version would need a LOT of requirements gathering before we even begin programming. It probably should include support for: * lots of encodings, but use Unicode internally * user-space pluggability for extra-heavyweight stuff like Japanese input methods or fonts * bidi text (Arabic) * variable width fonts (CJK), * variable-width encodings (Unicode combining chars), * absolute positioning for things like line drawing... * ANSI / ECMA and VT100 compatibility Hmmm... I suspect I've hardly even scratched the surface and already this looks like it's going to be way too big for the kernel. Maybe the entire thing should be in user space. How important is it to have an in-kernel console? Chris -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
