On Fri, 25 Feb 2000, Petr Vandrovec wrote:
>> >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).
Oh no, you misunderstand! 64 is PLENTY! I'd never use that
many. What I meant is that I don't want the number of VC's to be
restricted by the RAM size of the video hardware. I don't care
if it is slower or not, just as long as it works.
>> 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.
I agree, which is why I'm not suggesting that anyone be forced to
use it. If ANY change is made, I want the code to be a CONFIG
option, and *NOT* MANDATORY. After that, if a user chooses to
use it, I want it to not be active until a userland app actually
enables it. That way any user can decide on their own wether or
not they WANT the feature, and after that, how much memory THEY
are willing to give up to have the feature, and perhaps mark some
consoles as not having scrollback at all.
I for one would give up several megs of RAM for scrollback. The
userland app that configures it could be reran to recall the RAM
when you don't need the scrollback again.
No user will complain that the thing is too big if they are the
ones who requested the feature to use that much memory in the
first place, especially when the default will be exactly what is
there now.
I don't want anyone to have a surprise feature thrown at them.
>> 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).
Exactly. Which is why my proposal is to have a userland app
inform the kernel of the necessary modelines, fonts, clocks to
use. Thus the kernel does not start out knowing about anything
more than it does now. Your startup scripts run an app which is
something like SVGAtextmode which informs the kernel how to
change to the modes that will be used, and then tells the kernel
what mode each VC is supposed to be in.
Do you see anything I'm missing in the above? I think it is
possible, but I'm not 100% sure. I'd like other people's
feedback.
Again, I must stress that I'm not keen on bloating the kernel at
all. I want minimal stuff in kernel to do the job, and I want
any changes to be made CONFIG_XXX options so that those that
absolutely don't want them can opt out, and have exactly what
they have now.
If that can't be done, then I don't want it in the main kernel
tree at all, but rather just in my own system. I don't want any
features forced on everyone.
>> 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?
I realize all that... It was just a cool idea... I don't know
how feasible it really is, and am not interested in trying to
code it up either right now. If I ever do, it will be long after
the other stuff that I do really want.
>> 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.
Ok, can anyone tell me where to get the vgafb code? If it does
what I'm looking for, I'd be glad to have something to start
with.
>> 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.
Is this really true? Could I not have a userland interface which
a special app could tell the kernel these things at runtime? If
it is impossible, I'd like to know why, or is it just really
complex?
I admit that I'm not that familiar with the code, so forgive me
if it is really complex an idea.
>> 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.
Hmm. So a userland app would have to know what video card you
have. This could be done with autodetection, or by the user
picking a card. I don't see this a problem because you need to
do the same for X, or for any other OS out there anyways. Once
the card is known by a userland app, it can inform the kernel of
this somehow no? I mean not with what we have now, but we could
extend the kernel in this manner no?
>> 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
>dotclocks.
Ok, then it does sound feasible. The dotclock code can be stolen
from SVGATextMode, as long as it is GPL I guess. At least it can
provide me with an idea of the details necessary.
>> 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.
My monitor is a new one.
>> 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?
Sorry, "anything" above is not true. "Some things" "some
people" have suggested - is how it should read.
>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.
This sounds very much to me like what I want it to do indeed.
>(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).
That sounds acceptible to me. I don't want to just see numbers
and give up. I want to see the working code (and I'm willing to
learn how to write it), and THEN if it sucks, ditch it. I have a
feeling that it won't suck though - at least for me.
>> >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).
Allright, you've convinced me that vgafb is the way to go. If it
can do what I want with some work, and nobody else is interested,
I'll work on it alone and extract braincells or info from you all
to aide me in my quest.
If I get it working, I most certainly will maintain it as long as
I am using it myself - which will likely be until the sun
implodes because I hate GUI stuff when text mode does the
job. ;o)
Just point me to the vgafb code, and I'll have a look-see. That
is from the 2.1.x era correct?
Thanks very much for your VERY useful information! I've learned
a fair bit about this stuff now.
Take care!
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocateSuspicious Anagram #4: Word: PRESIDENT CLINTON OF THE USA Anagram: TO COPULATE HE FINDS INTERNS
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:13 EST