vt: Do not clear UTF when resetting console
PATCH 1/1 vt: Do not clear UTF when resetting console
Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode. Fix this by leaving the field vc_data.vc_utf untouched in reset_terminal(). In addition, a global variable (default_utf8) which defines system-wide UTF-8 setting is created. This variable can be adjusted via sysfs.
This is based from patches by Jan Engelhardt and Paul LeoNerd Evans.
---
drivers/char/vt.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
drivers/char/vt.c +3 -1
@@ -157,6 +157,8 @@ static void blank_screen_t(unsigned longstatic void set_palette (struct vc_data *vc);static int printable;/* Is console ready for printing? */ +static int default_utf8; +module_param (default_utf8, int,S_IRUGO |S_IWUSR );/* * ignore_poke: don't unblank the screen when things are typed. This is
@@ -1497,7 +1499,6 @@ static void reset_terminal(struct vc_dat vc->vc_charset =0 ; vc->vc_need_wrap =0 ; vc->vc_report_mouse =0 ; - vc->vc_utf =0 ; vc->vc_utf_count =0 ; vc->vc_disp_ctrl =0 ;
@@ -2590,6 +2591,7 @@ static void vc_init(struct vc_data *vc, vc->vc_rows = rows; vc->vc_size_row = cols <<1 ; vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row; + vc->vc_utf = default_utf8;set_origin (vc); vc->vc_pos = vc->vc_origin;
Quoted 5 lines · Antonino A. Daplas
Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode. Fix this by leaving the field vc_data.vc_utf untouched in
reset_terminal(). In addition, a global variable (default_utf8) which defines system-wide UTF-8 setting is created. This variable can be adjusted via sysfs.
If you're going to introduce a system-wide default, instead of issuing the appropriate escape code, then I would argue it should still be forced (to the default) when issuing a console reset.
-hpa
Quoted 9 lines · Antonino A. Daplas
Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode. Fix this by leaving the field vc_data.vc_utf untouched in
reset_terminal(). In addition, a global variable (default_utf8) which defines system-wide UTF-8 setting is created. This variable can be adjusted via sysfs.This is based from patches by Jan Engelhardt and Paul LeoNerd Evans.
Signed-off-by Antonino Daplas <[email protected]>
Quoted 4 lines
---
drivers/char/vt.c| 4 +++-1 files changed, 3 insertions(+), 1 deletions(-)
BTW. Is it feasible to make utf8 the default (static int default_utf8 = 1) or is that likely to break some installs?
drivers/char/vt.c static void blank_screen_t(unsigned long · line 161
Quoted 3 lines
static int printable; /* Is console ready for printing? */
drivers/char/vt.c +2
-0+static int default_utf8; +module_param (default_utf8, int,S_IRUGO |S_IWUSR );
It's probably just me, but I would have used an unsiged int.
Jan
Quoted 11 lines · H. Peter Anvin
Quoted 5 lines · Antonino A. Daplas
Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode. Fix this by leaving the field vc_data.vc_utf untouched in
reset_terminal(). In addition, a global variable (default_utf8) which defines system-wide UTF-8 setting is created. This variable can be adjusted via sysfs.If you're going to introduce a system-wide default, instead of issuing the appropriate escape code, then I would argue it should still be forced (to the default) when issuing a console reset.
That would be the cleanest and purest behavior. But it's possible to set one console to UTF-8 and another to legacy mode. So one can corrupt the user's console just by issuing a reset or echo -e '\033c'. (Although one can argue that users who know what UTF-8 is also knows how to set the encoding back)
Until userspace is more capable of setting back the terminal to its previous configuration, I would tend to agree with Jan, that we should leave the current utf setting of that particular vc alone.
Tony
Quoted 14 lines · Jan Engelhardt
Quoted 9 lines · Antonino A. Daplas
Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode. Fix this by leaving the field vc_data.vc_utf untouched in
reset_terminal(). In addition, a global variable (default_utf8) which defines system-wide UTF-8 setting is created. This variable can be adjusted via sysfs.This is based from patches by Jan Engelhardt and Paul LeoNerd Evans.
Signed-off-by Antonino Daplas <[email protected]>Signed-off-by Jan Engelhardt <[email protected]>
Quoted 8 lines
Quoted 4 lines
---
drivers/char/vt.c| 4 +++-1 files changed, 3 insertions(+), 1 deletions(-)BTW. Is it feasible to make utf8 the default (static int
default_utf8= 1) or is that likely to break some installs?
I guess it would, but most if not all major distribs are moving/have moved to utf-8.
Tony
Quoted 3 lines · Antonino A. Daplas
That would be the cleanest and purest behavior. But it's possible to set one console to UTF-8 and another to legacy mode.
The question would be: why would you want to have mixed consoles? Switching to UTF8 IMO does not take away any characters, and I mean no-framebuffer 80x25 that is limited to 256 glyphs.
Jan
Quoted 8 lines · Jan Engelhardt
Quoted 3 lines · Antonino A. Daplas
That would be the cleanest and purest behavior. But it's possible to set one console to UTF-8 and another to legacy mode.
The question would be: why would you want to have mixed consoles? Switching to UTF8 IMO does not take away any characters, and I mean no-framebuffer 80x25 that is limited to 256 glyphs.
As long as we provide the users the capability to support mixed encodings, the why is not important, it will happen. If we want to be more restrictive, I guess, we can remove support for
echo -e '\033%G' and '\033%@'
Tony
Quoted 8 lines · Jan Engelhardt
Quoted 2 lines · Antonino A. Daplas
That would be the cleanest and purest behavior. But it's possible to set one console to UTF-8 and another to legacy mode.
The question would be: why would you want to have mixed consoles? Switching to UTF8 IMO does not take away any characters, and I mean no-framebuffer 80x25 that is limited to 256 glyphs.
512, not 256. However, the reason would be because you have an application (which might actually be running on another system entirely!) which expects the other behaviour.
Quoted 9 lines · Antonio
That would be the cleanest and purest behavior. But it's possible to set one console to UTF-8 and another to legacy mode. So one can corrupt the user's console just by issuing a reset or echo -e '\033c'. (Although one can argue that users who know what UTF-8 is also knows how to set the encoding back)
Until userspace is more capable of setting back the terminal to its previous configuration, I would tend to agree with Jan, that we should leave the current utf setting of that particular vc alone.
I think you're missing the whole point of console reset. Its purpose is to force the console into a known-good state. The fewer pieces of state it leaves unset, the better. To some degree it's less important what that state actually is.
-hpa
Hello!
Quoted 2 lines
Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode.
Yes, and as far as I understand the logic behind these escape sequences, it's the intended behavior, not a bug.
The escape sequence for terminal reset should reset as much as possible, I see no reason for making an exception for the UTF-8 mode.
Have a nice fortnight
Signature · 3 lines
Martin `MJ' Mares <[email protected]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Lottery -- a tax on people who can't do math.
Quoted 8 lines · Martin Mares
Quoted 2 lines
Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode.
Yes, and as far as I understand the logic behind these escape sequences, it's the intended behavior, not a bug.
The escape sequence for terminal reset should reset as much as possible, I see no reason for making an exception for the UTF-8 mode.
Does whatever defines what these escapes mean, have any comment to make about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset" mode, the default that would be dropped to on a full reset, and if anyone wanted to switch that out to non-default not-UTF-8 mode, they could, but that a reset will always reenable it again..?
Signature · 5 lines
Paul "LeoNerd" Evans [email protected] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Hello!
Quoted 5 lines
Does whatever defines what these escapes mean, have any comment to make about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset" mode, the default that would be dropped to on a full reset, and if anyone wanted to switch that out to non-default not-UTF-8 mode, they could, but that a reset will always reenable it again..?
Maybe it would be a little bit more convenient, but I doubt that such bit of convenience justifies breaking backward compatibility.
Have a nice fortnight
Signature · 3 lines
Martin `MJ' Mares <[email protected]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth A computer without Windows is like a chocolate cake without mustard.
Quoted 4 lines · On Mon, 02 Apr 2007 17:55:43 -0700 "H. Peter Anvin" <[email protected]> wrote:
I think you're missing the whole point of console reset. Its purpose is to force the console into a known-good state. The fewer pieces of state it leaves unset, the better. To some degree it's less important what that state actually is.
Ultimately, does the patch actually change that?
Without this change, utf mode gets reset to zero because that's what the kernel source code says.
With this change, utf mode gets reset to zero because that's what the module parameter says and the user hasn't changed it..
.. only with the change, users get the ability to change that policy.
For the last 2 years since I originally submitted that patch, I've been running it on my box. For those last 2 years, finally, UTF-8 input actually worked on the VTs. Previous to that, lots of things broke.
Signature · 5 lines
Paul "LeoNerd" Evans [email protected] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Quoted 10 lines · Martin Mares
Hello!
Quoted 5 lines
Does whatever defines what these escapes mean, have any comment to make about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset" mode, the default that would be dropped to on a full reset, and if anyone wanted to switch that out to non-default not-UTF-8 mode, they could, but that a reset will always reenable it again..?
Maybe it would be a little bit more convenient, but I doubt that such bit of convenience justifies breaking backward compatibility.
Please note that I have dropped this patch in favor of this one:
http://lkml.org/lkml/2007/4/2/422
This patch behaves exactly as the one Paul posted before.
Tony
Quoted 7 lines · Antonino A. Daplas
Quoted 7 lines
Quoted 6 lines
Does whatever defines what these escapes mean, have any comment to make about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset" mode, the default that would be dropped to on a full reset, and if anyone wanted to switch that out to non-default not-UTF-8 mode, they could, but that a reset will always reenable it again..?
Quoted 6 lines
Quoted 2 lines
Maybe it would be a little bit more convenient, but I doubt that such bit of convenience justifies breaking backward compatibility.
Please note that I have dropped this patch in favor of this one:
^^ Which is ok by me.
Jan
Quoted 7 lines · Jan Engelhardt
Quoted 3 lines · Antonino A. Daplas
Please note that I have dropped this patch in favor of this one:
^^ Which is ok by me.
I agree - Does The Right Thing as far as I'm concerned.
Signature · 5 lines
Paul "LeoNerd" Evans [email protected] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
Hello!
Quoted 3 lines
Please note that I have dropped this patch in favor of this one:
Yes, this sounds very reasonable.
Have a nice fortnight
Signature · 3 lines
Martin `MJ' Mares <[email protected]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Ctrl and Alt keys stuck -- press Del to continue.