[coreboot] libpayload, coreinfo: ACS support

[Ulf Jordan]

On Mon, 11 Aug 2008, Jordan Crouse wrote:

> On 10/08/08 16:42 +0200, Ulf Jordan wrote:
>> Add support for line drawing characters and the alternate character set.
>> This enables using the ACS_ curses macros with libpayload.
>>
>> The translation from ACS_ macros (or characters with attribute A_ALTCHARSET)
>> is done using one acs map for the video console, one for serial console
>> (xterm/vt100/vt220), and one fallback, from which an ASCII substitute is
>> taken if the device specific map doesn't contain an entry (ie NUL).
>>
>> coreinfo is also adapted to take advantage of the symbolic ACS_ constants.
>>
>> Signed-off-by: Ulf Jordan <jordan at chalmers.se>
>
> This adds a lot of extra .data space.

Yes, this patch is a bit clumsy.

There are several ways to make it less hard on .data space. One way would 
be to have all *_acs_maps in .bss, and initialize them at runtime in 
initscr() from the much shorter acsc strings (about 64 bytes per map).

I will try to make a quantitative comparison on the growth of e.g. 
coreinfo and coreinfo+coreboot-v3 with both the original patch and the 
scheme outlined above.

> What do we lose if we don't support alternate character sets?

(First a side note: this is not general support for different character 
sets, but support for *the* special graphics/"alternate character set".)

Well, my motivation for implementing ACS support is twofold:

1. Let curses applications continue to use ACS_HLINE when drawing lines 
etc (in the current code this could at least partially be supported by 
initializing acs_map with the magic characters '\304' and so on). 
Consequently, less porting to do when compiling a curses application 
against libpayload, and the code stays more readable. The patch also adds 
fallback ASCII characters for the entire set, not just the line drawing 
part.

2. Better fidelity between what is seen on VGA console and serial console. 
After applying the ACS and companion color patch, the serial output in 
xterm looks close to identical to the QEMU VGA (there is still some 
misalignment due to outputing characters in C0, but that is for a later 
patch).

I do recognize that sometimes one wants to have very simple serial output, 
and sometimes one wants eye candy.

> Mabye we can make this conditional in the kconfig.

Yes, good idea. I think it would be nice to be able to switch between 
"pure ASCII+cursor positioning" and "all bells and whistles" over serial.


/ulf