[BRLTTY] Broken colour names

[Aura Kelloniemi]

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:
 > Samuel Thibault, on Tue 17 Nov 2015 10:07:37 +0100, wrote:
>> Aura Kelloniemi, on Tue 17 Nov 2015 10:23:33 +0200, wrote:
>> > I could not get the blink attribute working on Linux console. Traditionally it
>> > changed the background colour to be bright, as the bold attribute does for the
>> > foreground colour.
>> 
>> The background color can not be made bright, only the foreground can
>> (and only when loading a 256-glyph font, not 512-glyph). That's a
>> hardware limitation in VGA boards.

 > Of course I should have checked what I was saying. As Dave says,
 > foreground can always be made bright, but background can not, and it's
 > the blink capability which is lost when loading more than 256 glyphs.

Yes, unfortunately it seems to be so. This is IMHO a stupid restriction during
the modern times when people are using framebuffer consoles.

Actually this is not the restriction of the VGA board, but only of the Linux
kernel. But kernel inherits the spirit of this restriction from the VGA board,
if I can say so.

PC BIOS has a bit in a reserved memory address which controls the behaviour of
the 7th bit of the attribute byte stored for every character in the text-mode
video RAM. The 7th bit can either control blinking or bright background
colour. This can be twiddled with if you can run some code on bare PC metal,
like in DOS.

And now I come to my point. VGA boards allow 512-character fonts to be used in
text-mode. But if this feature is activated, the bit 3 of the attribute byte
controls wheter the character is selected from the lower 256 characters' range
or from the upper. So, if real text-mode VGA is in use, using a font with
512 glyphs restricts the number of available foreground colours to 8, but it
still allows 16 background colours (or blinking, if desired).

Framebuffer console (luckily) does not implement this quirk, though it
unfortunately adds it's own one - using the 7th bit for controlling bright
background or extended font indexing.

Would somebody want to lobby the Linux folks that they would lift this
restriction - and at the same time allow for 1024-glyph fonts, or something
equally nice. Yes, it would require introducing low-level incompatibilities,
but nowadays there are very few applications which read from the VCSA devices
or use console ioctls. Perhaps in the future we have a user-space console
driver which does not have these problems, but now we don't have one, at least
not a mainstream one.

Or perhaps I should lobby BRLTTY folks to implement a screen driver for
kmscon. (This is one of the reasons why I want to use an X terminal emulator.)

-- 
Aura