[PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Adam Borowski]

Hi!
Here's a patchset with two entangled improvements:

* it'd be good to get rid of blinking where possible.  Even CGA (thus VGA)
  allows disabling it, rendering such characters with a bright background
  instead.
* due to my error, 256-color mode uses a much darker palette for conversion,
  resulting in behaving inconsistently with 24-bit mode.

The new code uses bright backgrounds when possible, enabled with \e[100m or
\e[48;m.

Despite the whole idea following a VGA capability, this patchset doesn't
change vgacon yet, just fbcon.  The reason being: ~80% of x86 users have an
nVidia chip, which means nouveau or nvidia-proprietary.  Nouveau implies
fbcon, nvidia-proprietary fails to properly restore text flags (as evidenced
by 512 glyph mode turning to 256 on switch from graphics).  You don't care
about the proprietary driver, but let's not break it pointlessly, and as
both nVidia cards I own work only with nouveau, I don't want to touch what I
can't test.

Thus, let's enable unblinking on fbcon for now.  We can flip that bit (in
register 0x10) later.

This fixes the display of catimg and similar tools.


Diffstat:
 drivers/tty/vt/vt.c              | 56 +++++++++++++++++++++++++++++---------------------------
 drivers/video/fbdev/core/fbcon.c |  1 +
 include/linux/console_struct.h   |  4 ++--
 3 files changed, 32 insertions(+), 29 deletions(-)

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.

[PATCH 1/6] vt: drop unused struct vt_struct

[Adam Borowski]

Hasn't been ever used within historic (ie, git) times.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 include/linux/console_struct.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 2c8d3239899b..fea64f2692a0 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -17,7 +17,6 @@
 #include <linux/vt.h>
 #include <linux/workqueue.h>
 
-struct vt_struct;
 struct uni_pagedir;
 struct uni_screen;
 
@@ -150,7 +149,7 @@ struct vc {
 	struct vc_data *d;
 	struct work_struct SAK_work;
 
-	/* might add  scrmem, vt_struct, kbd  at some time,
+	/* might add  scrmem, kbd  at some time,
 	   to have everything in one place - the disadvantage
 	   would be that vc_cons etc can no longer be static */
 };
-- 
2.18.0

[PATCH 2/6] vt: add console flag "unblinking"

[Adam Borowski]

Marks consoles that interpret the blink bit by showing bright background
instead.  Doesn't matter if the console can't do either.

For now, turn it on for fbcon when in color mode.  Vgacon can also do so
but requires setting appropriate VGA register (bit 3 of AMCR).  I don't
know other consoles: newport looks like it shows bright bg, sti can't do
either, mda appears to blink, etc -- but confirmation would be needed.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 drivers/tty/vt/vt.c              | 1 +
 drivers/video/fbdev/core/fbcon.c | 1 +
 include/linux/console_struct.h   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 846dfedb657d..45057bbf6f74 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -998,6 +998,7 @@ static void visual_init(struct vc_data *vc, int num, int init)
 	vc->vc_hi_font_mask = 0;
 	vc->vc_complement_mask = 0;
 	vc->vc_can_do_color = 0;
+	vc->vc_unblinking = 0;
 	vc->vc_panic_force_write = false;
 	vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS;
 	vc->vc_sw->con_init(vc, init);
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c910e74d46ff..4c67254f1ec4 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1092,6 +1092,7 @@ static void fbcon_init(struct vc_data *vc, int init)
 
 	vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT);
 	vc->vc_can_do_color = (fb_get_color_depth(&info->var, &info->fix)!=1);
+	vc->vc_unblinking = vc->vc_can_do_color;
 	vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
 	if (charcnt = 256) {
 		vc->vc_hi_font_mask = 0;
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index fea64f2692a0..f94b28a6bd2d 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -122,6 +122,7 @@ struct vc_data {
 	unsigned int	vc_ques		: 1;
 	unsigned int	vc_need_wrap	: 1;
 	unsigned int	vc_can_do_color	: 1;
+	unsigned int	vc_unblinking   : 1;	/* shows bright bg for blink */
 	unsigned int	vc_report_mouse : 2;
 	unsigned char	vc_utf		: 1;	/* Unicode UTF-8 encoding */
 	unsigned char	vc_utf_count;
-- 
2.18.0

[PATCH 3/6] vt: let \e[100m use bright background if unblinking

[Adam Borowski]

Let's keep \e[5m setting this bit, it's a nice way to convey the
information, and it preserves old behaviour.  Some other terminals
that can't or don't want to blink do so as well.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 drivers/tty/vt/vt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 45057bbf6f74..4096093c8cd2 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1709,6 +1709,8 @@ static void csi_m(struct vc_data *vc)
 			if (vc->vc_par[i] >= 90 && vc->vc_par[i] <= 107) {
 				if (vc->vc_par[i] < 100)
 					vc->vc_intensity = 2;
+				else if (vc->vc_unblinking)
+					vc->vc_blink = 1;
 				vc->vc_par[i] -= 60;
 			}
 			if (vc->vc_par[i] >= 30 && vc->vc_par[i] <= 37)
-- 
2.18.0

[PATCH 4/6] vt: change 256-color palette to match all(?) modern terminals

[Adam Borowski]

Turns out that osso-xterm which I based upon uses something a lot different
from apparently any other terminal -- they all use identical shades, much
brighter than what I copied:

    Old: 00 2a 55 7f aa d4
    New: 00 5f 87 af d7 ff

This did hardly matter as we immediately shoehorn the colors into only 16
values, but recently 24-bit codes turned from an oddity to something
widespread, thus it's better to handle 256 vs 24-bit consistently.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 drivers/tty/vt/vt.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 4096093c8cd2..8c61caafdf3c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1545,9 +1545,12 @@ static void rgb_from_256(int i, struct rgb *c)
 		c->g = i&2 ? 0xff : 0x55;
 		c->b = i&4 ? 0xff : 0x55;
 	} else if (i < 232) {   /* 6x6x6 colour cube. */
-		c->r = (i - 16) / 36 * 85 / 2;
-		c->g = (i - 16) / 6 % 6 * 85 / 2;
-		c->b = (i - 16) % 6 * 85 / 2;
+		int r = (i - 16) / 36;
+		int g = (i - 16) / 6 % 6;
+		int b = (i - 16) % 6;
+		c->r = r ? r * 0x28 + 0x37 : 0;
+		c->g = g ? g * 0x28 + 0x37 : 0;
+		c->b = b ? b * 0x28 + 0x37 : 0;
 	} else                  /* Grayscale ramp. */
 		c->r = c->g = c->b = i * 10 - 2312;
 }
-- 
2.18.0

[PATCH 5/6] vt: compensate for brightening the 256-color palette

[Adam Borowski]

The algorithm for 256-to-16 conversion was designed with wrong input
palette but actually tuned on mainstream GUI terminals.  This resulted in
something that works well only for data we convert ourselves (ie, 256 not
24-bit).

As the change is non-linear, I did not bother replicating it exactly, thus
there are some differences, among others:
* values very close to black go to 0 (black) rather than 8 (dark grey)
* grayscale ramp is more even

A comparison of the old vs new vs FreeBSD's teken is at:
https://github.com/kilobyte/colorkernel

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 drivers/tty/vt/vt.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8c61caafdf3c..c777f4c91df0 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1559,17 +1559,17 @@ static void rgb_foreground(struct vc_data *vc, const struct rgb *c)
 {
 	u8 hue = 0, max = max3(c->r, c->g, c->b);
 
-	if (c->r > max / 2)
+	if (c->r > max / 2 + 32)
 		hue |= 4;
-	if (c->g > max / 2)
+	if (c->g > max / 2 + 32)
 		hue |= 2;
-	if (c->b > max / 2)
+	if (c->b > max / 2 + 32)
 		hue |= 1;
 
-	if (hue = 7 && max <= 0x55) {
+	if (hue = 7 && max <= 0x70) {
 		hue = 0;
 		vc->vc_intensity = 2;
-	} else if (max > 0xaa)
+	} else if (max > 0xc0)
 		vc->vc_intensity = 2;
 	else
 		vc->vc_intensity = 1;
-- 
2.18.0

[PATCH 6/6] vt: support bright backgrounds for \e[48m if unblinking

[Adam Borowski]

This improves schemes used by fancy new programs.  For example, it lets
bright powerline segments match, and fixes images shown by catimg being
striped to the point of unreadability.

Handling of 8-color backgrounds uses stripped 16-color value instead of a
dedicated formula; this works worse for dark and better for bright inputs.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 drivers/tty/vt/vt.c | 38 +++++++++++++++++---------------------
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index c777f4c91df0..7fcb0ff2dccf 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1555,7 +1555,7 @@ static void rgb_from_256(int i, struct rgb *c)
 		c->r = c->g = c->b = i * 10 - 2312;
 }
 
-static void rgb_foreground(struct vc_data *vc, const struct rgb *c)
+static u8 rgb_to_16(const struct rgb *c)
 {
 	u8 hue = 0, max = max3(c->r, c->g, c->b);
 
@@ -1566,22 +1566,12 @@ static void rgb_foreground(struct vc_data *vc, const struct rgb *c)
 	if (c->b > max / 2 + 32)
 		hue |= 1;
 
-	if (hue = 7 && max <= 0x70) {
-		hue = 0;
-		vc->vc_intensity = 2;
-	} else if (max > 0xc0)
-		vc->vc_intensity = 2;
+	if (hue = 7 && max <= 0x70)
+		return 8;
+	if (max > 0xc0)
+		return hue | 8;
 	else
-		vc->vc_intensity = 1;
-
-	vc->vc_color = (vc->vc_color & 0xf0) | hue;
-}
-
-static void rgb_background(struct vc_data *vc, const struct rgb *c)
-{
-	/* For backgrounds, err on the dark side. */
-	vc->vc_color = (vc->vc_color & 0x0f)
-		| (c->r&0x80) >> 1 | (c->g&0x80) >> 2 | (c->b&0x80) >> 3;
+		return hue;
 }
 
 /*
@@ -1593,10 +1583,10 @@ static void rgb_background(struct vc_data *vc, const struct rgb *c)
  * Subcommands 3 (CMY) and 4 (CMYK) are so insane there's no point in
  * supporting them.
  */
-static int vc_t416_color(struct vc_data *vc, int i,
-		void(*set_color)(struct vc_data *vc, const struct rgb *c))
+static int vc_t416_color(struct vc_data *vc, int i, int bgshift)
 {
 	struct rgb c;
+	u8 v;
 
 	i++;
 	if (i > vc->vc_npar)
@@ -1615,7 +1605,13 @@ static int vc_t416_color(struct vc_data *vc, int i,
 	} else
 		return i;
 
-	set_color(vc, &c);
+	v = rgb_to_16(&c);
+
+	vc->vc_color = (vc->vc_color & (0xf0 >> bgshift)) | v << bgshift;
+	if (!bgshift)
+		vc->vc_intensity = (v & 8 >> 4) + 1;
+	else if (vc->vc_unblinking)
+		vc->vc_blink = v & 8 >> 4;
 
 	return i;
 }
@@ -1695,10 +1691,10 @@ static void csi_m(struct vc_data *vc)
 			vc->vc_reverse = 0;
 			break;
 		case 38:
-			i = vc_t416_color(vc, i, rgb_foreground);
+			i = vc_t416_color(vc, i, 0);
 			break;
 		case 48:
-			i = vc_t416_color(vc, i, rgb_background);
+			i = vc_t416_color(vc, i, 4);
 			break;
 		case 39:
 			vc->vc_color = (vc->vc_def_color & 0x0f) |
-- 
2.18.0

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Alan Cox]

On Wed, 18 Jul 2018 05:01:52 +0200
Adam Borowski <kilobyte@angband.pl> wrote:

> Hi!
> Here's a patchset with two entangled improvements:
> 
> * it'd be good to get rid of blinking where possible.  Even CGA (thus VGA)
>   allows disabling it, rendering such characters with a bright background
>   instead.

That's a matter of taste so needs to configurable. Changing the default
ought I think to be its own patch as it's a separate discussion to having
the choice there and easy to make.

For the palette why does it needs changing and exactly what standards
document defines 'right', especially given we don't do ICC in console
mode ? Have you tested the values used against multiple monitor types and
cards with a light meter ?

BTW visibly breaking the Nvidia crud is also fine. They'll then actually
bother to fix it and uually quite soon.

Alan

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Adam Borowski]

On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote:
> On Wed, 18 Jul 2018 05:01:52 +0200
> Adam Borowski <kilobyte@angband.pl> wrote:
> 
> > Hi!
> > Here's a patchset with two entangled improvements:
> > 
> > * it'd be good to get rid of blinking where possible.  Even CGA (thus VGA)
> >   allows disabling it, rendering such characters with a bright background
> >   instead.
> 
> That's a matter of taste so needs to configurable. Changing the default
> ought I think to be its own patch as it's a separate discussion to having
> the choice there and easy to make.

For vgacon yeah, you have a good point, as it can support either (and to be
exact, exactly one of the two as they share a hardware bit).  Only reason to
not have this configurable would be avoiding bloating the kernel with knobs
hardly anyone flips -- but you can already set minutiae like replacement
color for underline/italic/dim.  Thus you're right that if/when killing
blink on vgacon is implemented, it probably should be settable.

This is not an option on fbcon, though -- it can't blink (doable but I'm not
seeing anyone wanting to implement that) and already interprets that
attribute bit the way VGA would.  Thus, this patch merely makes vt behave a
way to match what the driver does.  This fixes some visual corruption in
certain user programs.

> For the palette why does it needs changing and exactly what standards
> document defines 'right', especially given we don't do ICC in console
> mode ? Have you tested the values used against multiple monitor types and
> cards with a light meter ?

You don't need a light meter for a difference of 53-out-of-256.  Most
desktop environments don't do ICC out of the box either, but there's an
assumption that whatever your monitor does, it gives the same result for the
same input (in the same lighting conditions).

That patch's purpose is:
* behave consistently between two APIs to set the same thing (\e[38;5;m vs
  \e[38;2;m) in a way that matches other terminals
* in case a future driver has better color handling we'd be different from
  other terminals

By the way, you can have ICC on console: "apt install vtgamma"
(https://github.com/kilobyte/vtgamma).

> BTW visibly breaking the Nvidia crud is also fine. They'll then actually
> bother to fix it and uually quite soon.

Yeah, but they haven't fixed 512-glyph yet (at least the last time I
looked), broken since day one.  In any case, this patchset doesn't support
vgacon yet, thus this is moot for now.  I picked the easy case (fbcon which
is always unblinking) over writing stuff to ports, we can update other
drivers later.

And vgacon has code that looks like it can do CGA and MDA (redundant with
mdacon?), either of which I haven't used in... quite a while.  Might be
tricky getting access to such hardware to test...


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Geert Uytterhoeven]

Hi Adam,

On Thu, Jul 19, 2018 at 4:29 PM Adam Borowski <kilobyte@angband.pl> wrote:
> And vgacon has code that looks like it can do CGA and MDA (redundant with
> mdacon?), either of which I haven't used in... quite a while.  Might be
> tricky getting access to such hardware to test...

Mdacon is meant to be used next to vgacon, for systems with both color and
monochrome graphics adapters.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Greg Kroah-Hartman]

On Wed, Jul 18, 2018 at 05:01:52AM +0200, Adam Borowski wrote:
> Hi!
> Here's a patchset with two entangled improvements:
> 
> * it'd be good to get rid of blinking where possible.  Even CGA (thus VGA)
>   allows disabling it, rendering such characters with a bright background
>   instead.
> * due to my error, 256-color mode uses a much darker palette for conversion,
>   resulting in behaving inconsistently with 24-bit mode.
> 
> The new code uses bright backgrounds when possible, enabled with \e[100m or
> \e[48;m.
> 
> Despite the whole idea following a VGA capability, this patchset doesn't
> change vgacon yet, just fbcon.  The reason being: ~80% of x86 users have an
> nVidia chip, which means nouveau or nvidia-proprietary.  Nouveau implies
> fbcon, nvidia-proprietary fails to properly restore text flags (as evidenced
> by 512 glyph mode turning to 256 on switch from graphics).  You don't care
> about the proprietary driver, but let's not break it pointlessly, and as
> both nVidia cards I own work only with nouveau, I don't want to touch what I
> can't test.
> 
> Thus, let's enable unblinking on fbcon for now.  We can flip that bit (in
> register 0x10) later.
> 
> This fixes the display of catimg and similar tools.

I've applied the first patch, as it was obvious :)

For the rest, can you make it a config option as Alan said?  And I
agree, we don't care about breaking nvidia systems, go ahead :)

thanks,

greg k-h

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Adam Borowski]

On Sat, Jul 21, 2018 at 09:43:19AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 18, 2018 at 05:01:52AM +0200, Adam Borowski wrote:
> > Here's a patchset with two entangled improvements:
> > 
> > * it'd be good to get rid of blinking where possible.  Even CGA (thus VGA)
> >   allows disabling it, rendering such characters with a bright background
> >   instead.
> > * due to my error, 256-color mode uses a much darker palette for conversion,
> >   resulting in behaving inconsistently with 24-bit mode.
> > 
> > The new code uses bright backgrounds when possible, enabled with \e[100m or
> > \e[48;m.
> > 
> > Despite the whole idea following a VGA capability, this patchset doesn't
> > change vgacon yet, just fbcon.  [Not breaking nvidia-proprietary.]
> > 
> > Thus, let's enable unblinking on fbcon for now.  We can flip that bit (in
> > register 0x10) later.
> > 
> > This fixes the display of catimg and similar tools.
> 
> I've applied the first patch, as it was obvious :)
> 
> For the rest, can you make it a config option as Alan said?  And I
> agree, we don't care about breaking nvidia systems, go ahead :)

The only thing such an option would be able to set is disabling blinking on
vgacon, which is not yet implemented.  fbcon never blinks, and the only case
it can't display bright background is 1-bit black&white.

I probably should change the line in fbcon:
+       vc->vc_unblinking = vc->vc_can_do_color;
to always use 1, but it doesn't matter either way.  Only difference would be
matching the variable name ("unblinking" vs "shows_bright_bg").

Console drivers can interpret that bit of attribute as:
* blinking (vc_unblinking = 0)
* bright background (vc_unblinking = 1)
* neither (result is ignored down the pipeline)

The matrix is:
                color                                     b&w
-------+-------------------------------------------+--------------
fb            bright bg                                 neither
mda              N/A                                     blink
newport      ?bright bg?                                 ?N/A?
sti           ?neither?                                    ?
vga      CGA/VGA: hardware switch (write to port)      MDA: blink
sisusb            ?                                        ?

Technically, every console can be made to blink by drawing/clearing affected
characters a few times per second, but that'd be quite a waste of coding
time and kernel size.  There's a reason browsers dropped support for <blink>
and text-decoration:blink.

This patchset doesn't drop blink in any case that was supported before,
though.  I did the easy part used by most people first (fbcon), so it can be
reviewed/merged.  Doing the hard part is quite pointless if this is NAKed
(but obviously doesn't require actual merging).

But perhaps by "option" you mean letting the user drop blink with no
replacement, which might also be a good idea if configurable?


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Geert Uytterhoeven]

Hi Adam,

On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski <kilobyte@angband.pl> wrote:
> Technically, every console can be made to blink by drawing/clearing affected
> characters a few times per second, but that'd be quite a waste of coding
> time and kernel size.  There's a reason browsers dropped support for <blink>
> and text-decoration:blink.

It's very simple and fast to implement in fbcon for FB_TYPE_PLANES or
FB_TYPE_INTERLEAVED_PLANES and FB_VISUAL_PSEUDOCOLOR ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Adam Borowski]

On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote:
> On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski <kilobyte@angband.pl> wrote:
> > Technically, every console can be made to blink by drawing/clearing affected
> > characters a few times per second, but that'd be quite a waste of coding
> > time and kernel size.  There's a reason browsers dropped support for <blink>
> > and text-decoration:blink.
> 
> It's very simple and fast to implement in fbcon for FB_TYPE_PLANES or
> FB_TYPE_INTERLEAVED_PLANES and FB_VISUAL_PSEUDOCOLOR ;-)

Interesting...  I'm still not going to do the effort to implement that
(which would require learning fbdev internals first), though.  But while I
dislike this feature, someone else might want it.

The main problem here is that there are only 8 or 7 bits available for
attributes, thus it's better to use them for something more useful.  And
here, fbcon already interprets this bit as bright background, thus this
patchset makes vt use it instead of non-existant blink.

There'll be more bits available once attributes get migrated into uniscr --
either 11 or 32 bits depending on chosen implementation.  But I still
wouldn't go too wild with them: the console is meant for recovery tasks as
on any properly working system you can have an X terminal configured for
pixel-to-pixel identical behaviour as anything console can do.  Thus, only
cheap improvements to attributes make sense.  This patchset is currently at
+3 net lines, this certainly counts as cheap.

On the other hand, displaying the _glyph_ better would be worth some effort.
Nicolas' uniscr that's already in Greg's tree did most of the work, what
remains is a way to load and store a font with more glyphs (needs a sparse
representation).


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: [PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements

[Geert Uytterhoeven]

Hi Adam,

On Mon, Jul 23, 2018 at 12:42 PM Adam Borowski <kilobyte@angband.pl> wrote:
> On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote:
> > On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski <kilobyte@angband.pl> wrote:
> > > Technically, every console can be made to blink by drawing/clearing affected
> > > characters a few times per second, but that'd be quite a waste of coding
> > > time and kernel size.  There's a reason browsers dropped support for <blink>
> > > and text-decoration:blink.
> >
> > It's very simple and fast to implement in fbcon for FB_TYPE_PLANES or
> > FB_TYPE_INTERLEAVED_PLANES and FB_VISUAL_PSEUDOCOLOR ;-)
>
> Interesting...  I'm still not going to do the effort to implement that
> (which would require learning fbdev internals first), though.  But while I
> dislike this feature, someone else might want it.
>
> The main problem here is that there are only 8 or 7 bits available for
> attributes, thus it's better to use them for something more useful.  And
> here, fbcon already interprets this bit as bright background, thus this
> patchset makes vt use it instead of non-existant blink.

Even better that they are mutually exclusive ;-)  So it can work fine with
only 4 bitplanes.

That means bitplane 3 means either bright background (palette[8..15] are
the extra-bright versions of palette[0..7]) or blinking (palette[8..15]
alternate between palette[0..7] and all zeroes).

> There'll be more bits available once attributes get migrated into uniscr --
> either 11 or 32 bits depending on chosen implementation.  But I still
> wouldn't go too wild with them: the console is meant for recovery tasks as
> on any properly working system you can have an X terminal configured for
> pixel-to-pixel identical behaviour as anything console can do.  Thus, only
> cheap improvements to attributes make sense.  This patchset is currently at
> +3 net lines, this certainly counts as cheap.

Assumed all those systems are sufficiently powerful to still run X
(said the guy who once ran X with mem=2M on his Amiga, just to prove it could
 work ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds