During playing with the console subsystem several ideas crossed my mind, here
are some of them:
----
Font switching problems:
- fbcon_set_font allows certain font widths to represent miscellaneous
control commands (copy font from another console etc.), but there is
currently no way to set fonts with width != 8 as both PIO_FONT and
PIO_FONTX don't pass font width at all.
- As far as I see, fbcon doesn't support 512-character fonts
- Both PIO_FONT and PIO_FONTX set font for fg_console, not for the console
they are issued for and there is also no chance to force setting of font
for _all_ consoles at once. Also note that on VGA there's only one font
font for all consoles, but fbcon supports per-console fonts.
- The unicode mapping table gets reset when a font is reloaded.
- Newly opened consoles still get the default font, therefore I cannot
just use setfont in my startup scripts as I did before to get latin-2
font on all of my consoles.
I propose the following solution:
- Leave PIO_FONT and PIO_FONTX set fonts for _all_ consoles and reset the
unicode mapping table. The GIO_xxx counterparts fetch font from the
fg_console.
- Make vgacon download fonts to videoram only when called for fg_console.
- Introduce new ioctl for font operations, fed with a structure containing:
int command; // FONT_GET, FONT_SET, FONT_COPY etc.
int flags; // FONT_RESET_UNIMAP, FONT_GLOBAL, FONT_DEFAULT
^ ^- make it a default font
\-- affect all consoles
int width, height;
int num_chars;
char *buffer; // Pointer to buffer with font data
Replace sw->con_get_font and sw->con_set_font by sw->font_op and pass
a pointer to this structure, possibly doing copy_from/to_user for FONT_GET
and FONT_SET (but not for other commands) in console.c.
----
Yet another problem comes to my mind: Encoding of attributes. Current
console code just uses VGA attributes for all color displays and some other
variant which arose I don't know where for mono displays. The mono variant used
to be the old MDA/HGC encoding, but it was changed, making it impossible to use
in-vram buffers on monochrome PC videocards.
We could either decide to have device-specific attribute encoding (it could
be expressed by bit positions for colors/blink/intensity and and/xor masks
for inversion, removing all can_do_color tests in the code, but it would
make taking the screen over by another console drivers complex [we would have
to recode attributes, but we theoretically should be doing this as well
in current code due to can_do_color changes]) or making some magic translation
in scr_readw/writew. Yet another possibility is to introduce two optional
256-byte arrays for mapping of attributes between standard and per-console
encodings. The first solution seems superior to me.
----
We could also introduce some new console drivers:
o mdacon (to drive second display, probably better than using mdafb)
o pccon (light-weight replacement to vgacon lacking all those nifty features
like font switching, colormaps, blanking et cetera; useful primarily
as a boot console for people who want some other console to take
over after the system starts). Maybe few ifdef's in vgacon would
be sufficient.
If we make mdacon and some other console loadable as modules, it would
be wise to move take_over to generic code.
----
Another interesting thought: Make scrolling on the VGA even faster by not
copying the screen at all (cards capable of 64KB circular buffer only). There
is one caveat: the screen memory as presented to console.c must be contiguous,
therefore we would need to utilize the MMU to have two virtually adjacent copies
of the videoram. Probably not worth implementing, but it's a neat idea.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Always remember that you are absolutely unique ... just like everyone else."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu