On Mon, Jul 04, 2016 at 02:46:24PM +0200, Gerd Hoffmann wrote: > On Mo, 2016-07-04 at 11:11 +0200, Paolo Bonzini wrote: > > On 04/07/2016 10:16, Gerd Hoffmann wrote: > > > +static void sercon_set_color(u8 fg, u8 bg, u8 bold) > > > +{ > > > + sercon_putchar('\x1b'); > > > + sercon_putchar('['); > > > + sercon_putchar('0'); > > Add a sercon_putstr perhaps? > > We run in real mode, so passing around pointers isn't that easy. > Given this would make sense for constant strings only (like the 4-byte > clear-screen sequence) and not so much for variable stuff we might put > all strings in the global segment. > > Would this ... > > void sercon_putchar(char *ptr) > { > char c = GET_GLOBAL(ptr[0]); > [ ... ] > > ... work?
Yes. See output.c:puts_cs() as an example. It only works if it's a constant string (as opposed to a string built on the stack). > > > Maybe we can reuse the output buffer which we have anyway. Logic needs > > > reworked a bit. We can't just clear characters after printing them out > > > if we want be able to read them later, so we need a separate > > > pending-updates bit. Also should be bigger I guess, maybe 80 chars so > > > it can cover a complete line. > > > > 80x25 is just 2K... Perhaps it's simpler to just allocate the whole > > video buffer from the UMB or EBDA when serial console is in use? > > 4k, we need both character and attribute. But, yes, if we can allocate > that somewhere in real mode address space without running into memory > pressure this might be the best option. Unfortunately, the screen can be larger than 80x25. If a large buffer is desired, it's also possible to malloc_high() it and then use either: call32() to access it, or int1587 to read/write it (see ramdisk.c:ramdisk_copy() as an example). Either way it seems ugly. At one point I looked through the sgabios code and was able to understand how it did caching. I'll take another look and see if I can describe it. -Kevin