Re: Linux console driver maintainer?

From: Mike A. Harris (mharris@meteng.on.ca)
Date: Thu Feb 24 2000 - 17:42:38 EST


On Thu, 24 Feb 2000, Guest section DW wrote:

>> I've looked at the code and vc_resize() in console.c appears to
>> resize every single VC simultaneously. I'd like to make it not
>> do that, but I assume it does for a good reason. Anyone care to
>> explain why? If no great reason exists, I'd like to hack it up
>> to work just for me... I don't want to shoot myself in the foot
>> though in the mean time.
>
>When I wrote this code many years ago (I mean: dynamic allocation
>of consoles and resizing) my first version allowed for VCs all of a
>different size. However, that didnt work well for me, so I threw
>out all complications and only put the current code in the kernel.
>(Well, I don't know whether it still is the current code, haven't
>looked at it for five years.)
>
>What was wrong about different sizes?
>One thing was that the kernel does not have detailed information
>about all video cards and video modes, so cannot easily change
>video modes, so an external program was needed.

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...

I dunno, but I feel that there should be some way to do
it... Seems like a waste of the full functionality of the
hardware..

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...

>The present system, where Alt-RightArrow cycles through all
>consoles is easy and convenient, and needs no userspace
>support.

Yes, I mostly use ALT-Fx, but ALT-ARROW is very useful also.

>Another thing was that my monitor/videocard at that time
>required several seconds to stabilize after a mode change. So
>even with userspace support working with more than a single
>text mode was unpleasant.

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...

>But if you have hardware that handles mode changes well, and
>you have the user space support then it is quite possible to do
>what you want. Probably I would not change the kernel, but
>make a program listen to KeyboardSignal generated by Alt-UpArrow
>and let this program do a chvt LogVT followed by a mode change,
>and make the next KeyboardSignal change back to the original VT.
>In that way looking at the log and going back is pressing
>Alt-UpArrow twice, even better than Alt-Fn followed by Alt-Fm.
>It would be a 20-line program.

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.

How about this: An in kernel video mode selection driver? It
could have a nice frontend API to talk to like VESA text
modes. You could poll the driver and get a list of available
modes on your current card, then walk the list, and choose an
available mode. This would require that the mode tables be in
kernel, as well as the font, however the fonts are allready in
kernel anyways. To minimize the kernel bloat, userland tools
could "load" the kernel's internal video mode tables with known
modes for this card, and the needed fonts.

So, on kernel bootup, you'd get pretty much what you have now,
and the kernels existing built in "modes" would be all that is
available. A userland tool runs at boot time that determines
your video card from line 45393 of
/proc/drivers/videocards/pci/current_videocard_installed (to make
sure that proc bloats the kernel even more) ;o) which lets it
know what card/model you're using something like /proc/cpuinfo
lets you know what CPU you're using. This tool then loads fonts
and video mode settings off disk, and inserts them into the
kernel via ioctl, or.... even better, by sending xfree86 style
"modeline" strings directly into some other file buried 12 dirs
deep in proc which contains 500kb of text parsing code and then
loads the data tables... ;o) Hope everyone appreciates my
sense of humor here... WRT the /proc thread...

Anyways, now the kernels video modelist is created, and userland
apps can request a video mode, and font, from the currently
installed ones.

That way multiple VC's could be kept in different modes
simultaneously as long as the mode was available in the
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...

Thanks for the helpful reply!
Take care!
TTYL

-- 
Mike A. Harris                                     Linux advocate     
Computer Consultant                                  GNU advocate  
Capslock Consulting                          Open Source advocate

Suspicious 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:10 EST