From: Adam Borowski <hidden> Date: 2018-07-18 03:02:03
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.
From: Adam Borowski <hidden> Date: 2018-07-18 03:03:48
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 <redacted>
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
From: Adam Borowski <hidden> Date: 2018-07-18 03:03:50
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 <redacted>
---
drivers/tty/vt/vt.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
From: Adam Borowski <hidden> Date: 2018-07-18 03:03:53
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 <redacted>
---
drivers/tty/vt/vt.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
From: Adam Borowski <hidden> Date: 2018-07-18 03:04:01
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 <redacted>
---
drivers/tty/vt/vt.c | 38 +++++++++++++++++---------------------
1 file changed, 17 insertions(+), 21 deletions(-)
From: Adam Borowski <hidden> Date: 2018-07-18 03:04:10
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 <redacted>
---
drivers/tty/vt/vt.c | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
include/linux/console_struct.h | 1 +
3 files changed, 3 insertions(+)
On Wed, 18 Jul 2018 05:01:52 +0200
Adam Borowski [off-list ref] 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
From: Adam Borowski <hidden> Date: 2018-07-19 14:28:58
On Thu, Jul 19, 2018 at 11:47:49AM +0100, Alan Cox wrote:
On Wed, 18 Jul 2018 05:01:52 +0200
Adam Borowski [off-list ref] wrote:
quoted
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.
Hi Adam,
On Thu, Jul 19, 2018 at 4:29 PM Adam Borowski [off-list ref] 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
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
From: Adam Borowski <hidden> Date: 2018-07-21 21:38:58
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:
quoted
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.
Hi Adam,
On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski [off-list ref] 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
From: Adam Borowski <hidden> Date: 2018-07-23 10:42:07
On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote:
On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski [off-list ref] wrote:
quoted
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.
Hi Adam,
On Mon, Jul 23, 2018 at 12:42 PM Adam Borowski [off-list ref] wrote:
On Mon, Jul 23, 2018 at 10:53:29AM +0200, Geert Uytterhoeven wrote:
quoted
On Sat, Jul 21, 2018 at 11:39 PM Adam Borowski [off-list ref] wrote:
quoted
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