> 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 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.
> 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.
> 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 :)
> 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...
You just discribed the framebuffer console to a tee.
Codito, ergo sum - "I code, therefore I am"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
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