Re: Linux console driver maintainer?

From: Petr Vandrovec (
Date: Fri Feb 25 2000 - 15:06:33 EST

Hi Mike,
> >Its called fbdev :) Their was discussion on the list about using the
> >console layer to actually set different mode versus the current method of
> >using the fbdev layer to alter the console mode. Personally I agree with
> >you. I think the console layer should handle this.
> I just want the ability to run a VGA textmode console on a
> Trident 8900 with 512k of RAM without X windows installed and be
> able to:
> 1) Have as many VC's as I like - not restricted by video RAM
> size.
64 is not enough for you? I'm largest VT consumer of all I know and I'm
satisfied with 24 VTs (currently 25, as 25th is VMware fullscreen).
> 2) Have the OPTION of having separate scrollback buffers on each
> VC, each of which can be a different runtime configurable
> size.
Well, it was talked about couple of times and always shot down,
as with 32KB scrollback (current VGAcon does 4KB onscreen + 28KB scrollback)
it is 32KB per console unswappable memory, and as you may noticed, even
although such useful thing as devfs consumes 66KB, users complain that
it is too big. And 32KB * 64 VT = 2MB.
> 3) The ability to have each VC have its own TEXT MODE video mode,
> and have THE KERNEL be able to switch from VC to VC easily and
> change the video mode on its own without calling any userland
> stuff.
fbdev can do that. matroxfb supports native text modes (called
SVGALib compatible mode :-) ) and during 2.1.x there was vgafb
in kernel - it is what you are searching for. There is only one,
but big, problem. There is no problem with changing screen resolution
up to 255xMUCH screen (VT supports at most 255 columns, so no problem),
but standard VGA pixclocks are 25 or 28MHz, so without chipset knowledge
you can have at most 90 characters line. And with 16 lines character
cell height you can have at most 30 lines (60 lines with 8x8 chars).
> Optional idea:
> 4) Allow a VC to be split into 2, or 4 either horiz or vert, and
> have each treated like a separate VC. I guess another layer
> of abstraction would be needed.
It is very bad idea. Current consoles (both VGA and fbdev) are so
fast due to hardware panning - you do not move contents of memory,
but change only display start. If you are going to put multiple
VT on screen, you cannot use hardware panning anymore. I recommend
you either some of dualhead cards or building multihead system,
if you have such need. Also, you must have same resolution for all
these VCs, do not you?
> 1) Puts MINIMAL code in the kernel to do what needs to be done.
Dig vgafb somewhere, copy vgaHWinit & vgaHWrestore from matroxfb
and glue it together.
> 2) Does not bloat the kernel with details of every video card
> known to man or mode tables.
If you will not, you cannot switch pixclock to reasonable values,
you can have 12.6, 14.2, 25.3 and 28.5 MHz dotclock and nothing else.
> boot time (allready) can be changed to easily. A userland
> application can inform the kernel of new video modes at runtime
> by ioctl or some other interface deemed politically correct.
fbset passes complete videomode information to kernel. But kernel
has to pass it to hardware - and for this it must know about
hardware. Standard VGA is only standard VGA. Face to it.
> and loaded into the kernel by a userland app. The same userland
> app can tell the kernel to unload modes or fonts too.
> Seems simple in concept to me, and does not bloat the kernel at
> all - which is very important to me. I do not want 80 fonts and
> 40k of video mode tables being compiled into the kernel. The
Everything is ready in kernel, so use fbdev framework... You
supplies code which paints characters to screen (borrow from vgacon),
which programs font (borrow from vgacon), which programs vga hardware
(borrow from vga16fb or matroxfb) and which programs palette (vga16fb).
Only thing you have to add is pixclock programming code for unusual
> When I switch modes, it is fairly quick for me.. I guess it
> depends though..
With old monitors it is fast. New featurefull monitors needs some time
to recognize what's going on.
> Anything anyone has suggested thus far has been "do this - it
> solves one of the 5 problems you want to address, and only 7 side
> effects that are unpleasant result". No thanks. ;o)
Which 7 side effects? fbdev has only one, vcsa is no longer in
VGA memory, but kernel maintains copy for you. With current difference
between I/O and memory speeds I think that this argument is void.
(I recently added ioctl() which reads two hardware registers from
matrox. When I read two registers, 1e6 such ioctl()s is performed
in 2.05s on my system. If I remove one of register reads, it is done
in 1.70s - so two CPU operations take 30% of whole execution time,
which consist of transfering control from user->kernel->user, looking
up in several tables (file->ioctl->which ioctl) and couple of
math operations on read values).
> >You just discribed the framebuffer console to a tee.
> Really? But that is in graphics mode right? If the framebuffer
> is like that, it might be as simple as stealing some code from
> the framebuffer code and hacking it to work in "text mode". Or
> does it already do that?
vgafb was there, but was removed as no one was interested in maintaining
it and adding missing features into it (hw cursor support, non-std modes).
fbdev does not have to be graphics, it can be used by any hardware which
is able to show character on random position on screen (so not for
serial & parallel consoles).
                                Petr Vandrovec

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:13 EST