lkml.org 
[lkml]   [2000]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.224 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site