Date: Wed, 28 Jan 1998 10:38:29 +0100 (MET) From: Søren Schmidt <sos@FreeBSD.ORG> To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Cc: dag-erli@ifi.uio.no, hackers@FreeBSD.ORG, msmith@FreeBSD.ORG, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Graphical screen saver Message-ID: <199801280939.KAA08173@sos.freebsd.dk> In-Reply-To: <199801280640.PAA25860@zodiac.mech.utsunomiya-u.ac.jp> from Kazutaka YOKOTA at "Jan 28, 98 03:40:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Kazutaka YOKOTA who wrote:
>
> >The source is in /pub/FreeBSD/incoming/logo_saver.tgz on wcarchive.
> >You'll need to patch syscons.c to make it work; a unified diff and
> >rudimentary installation instructions are included in the tarball.
> >
> >As always, I appreciate feedback of any kind...
>
> I had a quick look at your graphical screen saver code. (And I have
> been following discussion between you and msmith :-)
>
> A couple of comments:
>
> The patch for syscons looks reasonable to me. (How do you think,
> Soeren?) When I touched this part of syscons last time, I didn't
> consider support for graphical savers (because at the time there was
> none ;-<
Seems OK to mee. Maybe I should just let UNKNOWN mode represent the
"real" unknown modes ie when the X server changes the resolution on
its own. syscons can deal with all the modes defined i console.h
and do sesnible things there. It will swallow up to 256K of kernel
memory pr saved image though. The only problem here is that the
process doing mem refs to the screen memory will have to be noticed
somehow, or it will sadly mess up the vga card & memory when off
screen, hmmm we cauld make it sleep and wake it on reentry to that
screen....
>
> I wonder if it's a good idea to let the screen saver to reschedule
> itself from inside the saver module.
No!
> With the above patch applied,
> syscons will periodically call the saver module. That should be
> sufficient for most purposes, I think. (Yet another timeout routine
> closely tied to syscons will add much complication...) The following
> fragment shows the flow I would suggest.
>
> logo_saver(int blank)
> {
> if (!blank) {
> /* restore the video mode */
> .....
> } else {
> if (scrn_blanked <= 0) {
> scrn_blanked = 1;
> /* switch video mode */
> .....
> logo_update();
> } else {
> /* if we want to update the screen in every other
> call, we can do the following */
> if (++scrn_blanked <= 2)
> return;
> scrn_blanked = 1;
> /* update the logo */
> logo_update();
> }
> }
> }
>
> In your code, video mode switching is protected by a splhigh()/splx()
> pair. I think splhigh() is overkill. We had better use spltty()
> instead.
yup.
> We have to be careful about VT switching while the graphical saver
> is active. I will check several things in syscons and contact you
> later. (I suspect we need to patch syscons...)
Well it should work, at least I have a graphics saver that used to
work :).
We might want to change the behavior of UNKNOW_MODE as noted above,
but I'm sure it will break at least a few of the graph progs out
there, but what the heck, if X still runs, and I make sure that
libvga works, then ....
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801280939.KAA08173>