Re: [PATCH] Fix to virtual terminal UTF-8 mode handling

[Paul LeoNerd Evans <leonerd@leonerd.org.uk>]

On Tue, 17 May 2005 19:58:48 -0700
Andrew Morton <akpm@osdl.org> wrote:

> Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
> >
> >  This patch fixes a bug in the virtual terminal driver, whereby the
> > UTF-8 mode is reset to "off" following a console reset, such as might
> > be delivered by mingetty, screen, vim, etc...
> 
> Is it a bug?  What did earlier kernels do?  2.4.x?

I haven't checked earlier 2.4 kernels, but I know the 2.6 ones have done
this for quite some time; a good year or so at least.

> Presumably userspace knows what mode the user wants the terminal to be
> using.  Shouldn't userspace be resetting that mode after a reset?

Well, that does require changes to a lot of the programs that talk to the
console, moreover, they now need to be sensitive to whether it is in
UTF-8 mode, where previously they did not. E.g. consider mingetty...

Also, as I understand it, there is one keyboard map, and one console font
for the entire virtual console system - either they are UTF-8, or not. It
doesn't really make sense to be switching these about.

Moreover, this code also affects dynamic creation of new virtual
consoles. E.g. when debian's "oh no, I can't start the X server" ncurses
dialog appears, without my patch it prints UTF-8 characters on a new
console, tty8, on a console that isn't set to display them, and mass
breakage results. Now, it all happens cleanly, because the new console is
already in UTF-8 mode.

Were this to be pushed to userland, every program that outputs data would
need to detect the UTF-8 mode of the console, and set it appropriately.
Moreover, they would need to perform this logic only on a Linux virtual
console; such things as XTerm or Gnome-terminal do it automatically.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

Attachment: pgpQg928SHNBL.pgp
Description: PGP signature