On Fri, 25 Feb 2000, James A Simmons wrote:
>> Ahhh... Right. I never thought of that... Well, hmm.. I guess
>> hooks could be put in place for a call to a userland tool/daemon
>> which could do the video mode change no? Or drivers that detail
>> various video modes for a given card somewhat like VESA text
>> modes could be put in-kernel...
>
>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.
2) Have the OPTION of having separate scrollback buffers on each
VC, each of which can be a different runtime configurable
size.
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.
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.
For all of the above, any solution that would be acceptible to me
would be one that:
1) Puts MINIMAL code in the kernel to do what needs to be done.
2) Does not bloat the kernel with details of every video card
known to man or mode tables.
The way I see accomplishing #2 is by having the kernel know about
the boot time video mode (ie: vga=ext), and *PERHAPS* the other
ones the bootup code knows about for existing cards and NOTHING
more. That way, any video mode that the kernel knows about at
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.
Then the kernel's internal "text mode" table, or linked list
could be added to or deleted from, with some modes being marked
"static" perhaps. These modes would also require font loading to
be included too. That way if a particular mode required a
different size font, it could be easily added to the linked list
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
only thing I see getting compiled into the kernel is what is
there allready, plus the ability to load stuff at runtime like I
described above.
>> I have another idea too... I normally use the 80x50 screen
>> mostly, however my card does 160x100 which is 4 times that. I
>> could subdivide the physical screen into 4 VC's and see 4
>> applications simultaneously. Say a couple manpages, an editor,
>> and PINE all on screen at once all in their own 80x50 "window" of
>> text.
>>
>> Crazy? Perhaps, but cool! I wonder how hard it would be to
>> do... along with the modeswitch thing that is...
>
>Kernel support for this would be insane. I would leave this up to a
>userland app to perform.
Why would it be insane? I'm not saying it wouldn't be.. just
wanting to know why? I haven't attempted to even dream of how to
do this, but I think it would be done via another layer in the
code. Scrolling routines and other stuff would likely need to be
modified. That might slow things down a bit, but it would be
OPTIONAL, not forced on anyone, and only there when you enable
the feature. It certainly would be faster than any userland
implementation.
>> Well, I could live with it mostly. I guess it depends on your
>> hardware, and what modes you're using. I'd only likely be using
>> 2 modes at once ever...
>
>I have noticed the delay as well when I change modes. Actally when I run
>graphics programs ontop of fbdev I have alot of my consoles at different
>resolutions.
I'm not too concerned with the time it takes for a mode change
personally. The way I look at it is:
If a person tries out the feature, and doesn't like the mode
change time, then they won't use the feature. Those that do not
mind it, will use the feature.
When I switch modes, it is fairly quick for me.. I guess it
depends though..
>> Problem with that is that all consoles still get resized and sent
>> SIGWINCH. Not all apps like that or respond to it nicely. Some
>> only respond to certain video modes in a nice manner.
>
>I see you want a console layer to handle this :)
Well I don't see how any other solution could be done
transparently. Using X is out of the question for many numerous
reasons that I won't even begin to get in to. Someone else
suggested "screen". That solution does do anything at all that I
asked for however, and just multiplexes the existing console as a
layer above what is there. It also hoses many color apps, and
its terminal emulation is not 1000% linux-console compatible. I
don't want any compromises in my solution, especially anything
that puts any amount of high overhead in userland, or user
inconvenience.
In other words, I want my cake, and I want to eat it too. ;o)
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)
>> modelist. Modes can be removed as needed from the modelist as
>> well, but not if they are in use.
>>
>> What do you think?
>>
>> Just some ideas...
>
>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?
I'm very interested in continuing this discussion with you, and
the others who have responded! It is making it look to me like
there is a light at the end of the tunnel that could bring the
Linux console into the year 2000. ;o) Actually, my guess is
that the console is allready better than anything else out there,
so... ;o)
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:12 EST