Messages in this thread | | | Date | Fri, 25 Feb 2000 10:18:18 -0500 (EST) | From | James A Simmons <> | Subject | Re: Linux console driver maintainer? |
| |
> I am pretty sure James was not referring to me but i have kept hacking > on the console code on and off for the last two years, trying to make > it a full ECMA (or ISO/IEC what ever you prefer) implementation with > as much DEC VT compatibility as possible.
Wow!! More people working on the console code. I know the console system discussion is on hold until 2.5.X but its nice to see people are actually thinking about it. I really like to see a project formed to handle the upcoming console issues. A linux-console project. A nice web page and mailing list where we can discuss issues. Sourceforge would be a nice place to set this up. This way we would be ready for the upcoming 2.5.X kernels.
> Attached is a work-in-progress patch against 2.3.40. Right now i am > thinking about how to implement real underlined, double underlined, > overlined, rapidly blinking attributes etc. That touches the fb > drivers as well. (Explanation: the IBM MDA/Hercules adaptors had > underlined attribute, CGA/EGA/VGA not. Instead the console driver > mapped it to a color attribute. With framebuffer console becoming > the standard, this is no longer necessary) > > The most difficult part (other than ECMA/ISO conformant character > and font handling) will be to implement bi-directionality (IIRC some > languages write right-to-left while numbers are written left-to-right, > or people might want to mix languages, so simply switching the character > progression does not cut it, there is more to do and that's why ECMA/ISO > implements special control functions for it). > > The easiest part will be to implement ECMA/ISO conformant color > handling (the ECMA/ISO sequences have defined colors like black, white > red, magenta,... instead of color registers). > > Yours, > Dominik Kubla
Nice ideas :)
> PS. And before someone thats to argue that this patch changes a lot > of code only cosmetically: console.c is so larges that it becomes > unmaintainable IMHO. So some of the changes are in preparation of > splitting it up into the device handling part, the console switching > stuff and the terminal emulation (which then could be made configurable. > who knows somemone might prefere a HP or Siemens emluation to DEC...)
I completely agree with you. You are not the only one working on this type of approach. I have seen others approach it this way. I personally like this approach.
P.S
So what does everyone say. We start a consoel project that everyone can work on and discuss the new design.
Codito, ergo sum - "I code, therefore I am" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |