Menu
▾
▴
linuxconsole-dev
|
From: Firstname L. <ms...@ho...> - 2000-03-10 19:43:42
|
> > > I'd eventually like to be able to set/reset on a per-console basis
> > > whatever video modes I like,
> >
> > Okay. Fbcon allows that to a limited degree.
>
>Really? Any idea how to do that? It's easy enough to get the fb
>working in some nice modes with a vesa-compliant chipset or a card
>which has its fb driver loaded, but I never really understood how to
>use the fbset command or its /etc/fb.modes file, or the /dev/fb*
>devices. And I had no idea that you could already set the fb into
>different modes on different consoles.
I do it like this. I switch the active VT to VT3 on monitor0 (/dev/fb0),
then telnet in from another machine, su, and type fbset 800x600-60. This
sets *just* VT3 to 800x600-60, all the others are still in thier old mode.
you can change the active console to VT4 on monitor0 and fbset 1024x768-60
and you will have VT3 at 800x600 and VT4 at 1024x768. VT1 and VT2 will
still be "classic" resolution.
>Using the fb modes was oh-wow for a while to amaze people with a tux
>or two at bootup, but in the end I have found it too much of a hassle
>to worry about any more.
>
>If the X driver or some svgalib application dropped out without
>resetting the fb mode correctly, then the local ttys became "lost" and
>unviewable. (Any way out of this?) svgalib is particular nasty to
>use with the console fb.
I've heard that the sysRq key is supposed to help. compile in "magic sysRq
key" support in the kernel, then press Alt-SysRq-{some letter which i
forgot}. i never got it working, cause i haven't had the problem and the
sysRq key at the same time, but *tell me if you get it working* I would very
much like to have the procedure for this figured out.
>I have been particular vulnerable to this
>since I've been using banshee and voodoo3 cards for quite a while and
>their drivers are vastly improving and still not 100% stable. I've
>also been meaning to have a good look at ggi, but too much to do and
>so little time...
>
>Anyway good luck with this project, it sounds very worthwhile.
>
>Cheers
>Tony
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
|
|
From: James S. <jsi...@ac...> - 2000-03-11 03:00:20
|
> >If the X driver or some svgalib application dropped out without
> >resetting the fb mode correctly, then the local ttys became "lost" and
> >unviewable. (Any way out of this?) svgalib is particular nasty to
> >use with the console fb.
Never ever use libsvga with fbdev. Both hit the hardware at the same time
and for low end hardware this locks the card or even damages it. As for
the X problem I have a patch that saves the console mode before opening
/dev/fb. If X dies then /dev/fb is closed which then restores the video
mode back to normal. Also fbdev drivers should be check all modes before
actually setting them so you can't set insane modes.
> I've heard that the sysRq key is supposed to help. compile in "magic sysRq
> key" support in the kernel, then press Alt-SysRq-{some letter which i
> forgot}.
Alt-SysRq-K
> i never got it working, cause i haven't had the problem and the
> sysRq key at the same time, but *tell me if you get it working* I would very
> much like to have the procedure for this figured out.
If you still set a insane mode often the fbdev drivers are not written
well enough to check the mode. This leaves the console in a undefine state.
Even the magic keys can't save you.
> >I have been particular vulnerable to this
> >since I've been using banshee and voodoo3 cards for quite a while and
> >their drivers are vastly improving and still not 100% stable. I've
> >also been meaning to have a good look at ggi, but too much to do and
> >so little time...
GGI take advantage of video hardware in any environment. Its preety neat.
I use Mesa-GGI so I can run OpenGL on the console with fbdev of course.
"Look it's a text editor, no it's a OS, no it's Emacs"
James Simmons ____/|
fbdev/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
|
|
From: Tony N. <to...@gr...> - 2000-03-14 02:48:46
|
On Fri Mar 10 2000 at 22:05, James Simmons wrote:
> > I've heard that the sysRq key is supposed to help. compile in "magic sysRq
> > key" support in the kernel, then press Alt-SysRq-{some letter which i
> > forgot}.
>
> Alt-SysRq-K
>
> > i never got it working, cause i haven't had the problem and the
> > sysRq key at the same time, but *tell me if you get it working* I would very
> > much like to have the procedure for this figured out.
less /usr/src/linux/Documentation/sysrq.txt
echo 1 > /proc/sys/kernel/sysrq
On redhat systems, in /etc/sysconfig/init you can change:
MAGIC_SYSRQ=no
to
MAGIC_SYSRQ=yes
But where it is set in /etc/rc.d/rc.sysinit it doesn't actually turn
this on - it only turns it off. I'm not sure what the bootup default
is, but if it is "0" then it is off. It needs to be "1" to be enabled.
The sysrq.txt file tells you how to use it from there.
It's a way cool feature. I used to use a "SAK patch" (Secure
Attention Key) on older kernels, but it is now a part of the kernel
with added functionality. This has got me out of several situations
where I would otherwise had to do a hard reboot because of a crashed
graphics app and the keyboard driver left in raw mode.
Beware though - this tweak is _not_ for beginners who don't know what
they are doing.
Cheers
Tony
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
Tony Nugent <To...@gr...> Systems Administrator, RHCE
GrowZone OnLine (a project of) GrowZone Development Network
POBox 475 Toowoomba Oueensland Australia 4350 Ph: 07 4637 8322
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
|
Thanks for helping keep SourceForge clean.
X