Edward H. Trager wrote on 2003-08-06: > On Wednesday 2003.08.06 08:29:37 -0400, Chris Heath wrote: > > > 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 > > Hmmm ... If I knew how to do this stuff myself (which I don't), I > would not bother with any encoding except Unicode UTF-8 (If people > did not like my patch, they wouldn't have to use it, right?). That > would cut down on the requirements and complexity a bit ... (a BIG > BIT, N'est-ce pas?). > > I (and many others ...) would argue that everyone needs to move to > Unicode. So when you buy that shiny new version of Linux 5 years in > the future, it's going to support Unicode very well, and it is > perhaps no longer going to support the 3-5 mutually incompatible > legacy encodings of your language that you previously had to > struggle with ... > This can actually work out. Just tell other people to run luit over the UTF-8-only console.
> > * user-space pluggability for extra-heavyweight stuff like Japanese > > input methods or fonts > > I wonder if the object oriented design of SCIM (Simple Common Input Method: > http://ns.turbolinux.com.cn/~suzhe/scim/index.html) could support CJK and > other IMs on the console? > > > * bidi text (Arabic) There is Akka from the arabeyes project which is supposed to give bidi over a non-bidi terminal. IIRC, last time I tried it didn't compile for me. Anybody had more luck with it? > > * variable width fonts (CJK), > > * variable-width encodings (Unicode combining chars), > > Yes, it would be nice if console worked as well as (or better than) > mlterm (http://mlterm.sourceforge.net/) does for bidi, ligatures and > combining characters for complex layout languages. > How do you do ligatures and combining characters within the limited text mode? Or do you mean only for the framebuffer mode? > > * absolute positioning for things like line drawing... You mean sub-charcell pixel-level positioning? I don't think we need to reinvent MGR, certainly the console is the least sensible place to experiment with non-text extensions to terminal emulators. > > * 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? > > It'd be pretty annoying if you could crash the console. Since it's in-kernel it's almost impossible (you can only stuck the video card in some mode the kernel doesn't understand ;-). But we do trust e.g. init(1) to be a user-space program. I don't see strong reasons why the console can't move to user-space, except for the fact that it currently has a lot of syscall/ioctl hooks and interfaces would have to be added to connect them to the user-space console process. But there is another good reason to keep the kernel console and it's non-unicode modes: there are very minimalistic builds of linux out there, a dumb in-kernel implementation where the buffer is in video memory is the most effective solution possible. -- Beni Cherniavsky <[EMAIL PROTECTED]> -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
