From: Adam Borowski Date: Fri, 12 Jul 2013 20:23:41 +0000 (+0200) Subject: vt: properly ignore xterm-256 colour codes X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=3415097ff0529eac264b8ccfa06572871e45c090;p=GitHub%2FLineageOS%2Fandroid_kernel_motorola_exynos9610.git vt: properly ignore xterm-256 colour codes This is not a bug on our side, but a misdesign in ITU T.416, yet with all popular terminals supporting these codes, people consider this to be a bug in Linux. By breaking the design principles behind SGR codes (gracefully ignoring unsupported ones should not require knowing about them), 256 colour ones tend to turn blinking on before invoking an arbitrary unrelated command. This commit doesn't add such support, merely skips such codes without ill effects. Signed-off-by: Adam Borowski Signed-off-by: Greg Kroah-Hartman --- diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index ef95c6c1698f..61b1137d7e56 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -1300,6 +1300,28 @@ static void csi_m(struct vc_data *vc) case 27: vc->vc_reverse = 0; break; + case 38: + case 48: /* ITU T.416 + * Higher colour modes. + * They break the usual properties of SGR codes + * and thus need to be detected and ignored by + * hand. Strictly speaking, that standard also + * wants : rather than ; as separators, contrary + * to ECMA-48, but no one produces such codes + * and almost no one accepts them. + */ + i++; + if (i > vc->vc_npar) + break; + if (vc->vc_par[i] == 5) /* 256 colours */ + i++; /* ubiquitous */ + else if (vc->vc_par[i] == 2) /* 24 bit colours */ + i += 3; /* extremely rare */ + /* Subcommands 3 (CMY) and 4 (CMYK) are so insane + * that detecting them is not worth the few extra + * bytes of kernel's size. + */ + break; case 39: vc->vc_color = (vc->vc_def_color & 0x0f) | (vc->vc_color & 0xf0); break;