Re: Unicode console patch

Stanislav V. Voronyi (stas@cnti.uanet.kharkov.ua)
Sun, 31 Jan 1999 17:52:08 +0200


In message <790f3b$3le$1@palladium.transmeta.com> H. Peter Anvin
writes:

>Followup to: <Pine.LNX.4.05.9901301738150.508-100000@qrnik.knm.org.pl>
>By author: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
>In newsgroup: linux.dev.kernel
>>
>> On Sat, 30 Jan 1999, Stanislav V. Voronyi wrote:
>>
>> > one useful feature from my patch - get/set all variables concerning to
>> > traslations (translate,charset,G0_charset,G1_charset,utf) with help of
>> > two additional TIOCLINUX ioctls.
>>

>Please don't extend TIOCLINUX. It was a bad mistake to begin with,
>and furthermore, we're trying to move away from ioctl()s (ioctl()s
>were used because most changes affected *all* consoles. Per-console
>changes should be done with escape codes.)

It is very useful to have posibilities to get the state of
translation related variables. Imo we don't have yet the wide UTF support
(in bash, vi, etc) just because there is not such posibility. In any
case the new console driver will be in 2.3 and imho it is not a bad
idea to have this posibilities in 2.2 as well. May be better do it
through the ESC sequences, but imo such posibility realy needed.
The ESC sequences allow to use this posibility not only on local console,
but through telnet or ssh conection, etc. I think I can do this,
but what the question - which ESC sequences have to be used to request
this information and what the format of response sequences ?

>I'm working on a completely new console spec that is ISO
>2022-compliant (the current console isn't, and cannot be made to be.)

If you need volunteers for this I am first.

>> Yes, it's really needed: checking UTF-8 mode by measuring cursor motion is
>> a pain, with side effects of flushing stdin. I need to examine the whole
>> translation mode info in one tool.
>>
>> I wonder if its ever possible to put this interface into xterm and telnet.

>One of the reasons I'm doing this is so non-console terminals will be
>able to accept the same interface.


>> BTW, where can I ask about framebuffer? Will it be possible to load more
>> than 512 characters? Will it be compatible with dosemu in its "graphics",
>> "non-console" mode? How to set fonts with a non-8 width? How about drivers
>> for various SVGA cards? My S3 Virge requires DOS univbe for VESA 2.0 - it
>> works, but is it safe - can Linux corrupt univbe's code, or maybe it uses
>> it only to switch the mode on?

>> Oh, one more thing: Linux standard line discipline erases only a single
>> byte with Backspace, even in UTF-8 mode, although on the screen the cursor
>> goes back the whole character. This needs fixing.

>Good spotting.

But can't be fixed easily. The N_TTY line discipline does not have
anything to support UTF. For local console I can get information from console
structures, but for something like ssh connection it is impossible. Even we
will have the way to ask console about modes through ESC sequnces it is
has no effect for line discipline. So we need to have in N_TTY its own flag
-utf to treat UTF-8 sequences correctly. But in this case line discipline
utf flag & console utf flag have to be simultaneous. It is easy for local
console, but I don't know how to do it for remote one ?

SY, Sanislav Voronyi.

-
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/