Well I've tried this on my Solaris box cause I just installed 2.21 of
xscreensaver today and it works fine.
2 things that are different
1.) I start xscreensaver with the -display option because it wasn't
getting the variable correctlly in my .fvwm2rc file
2.)I am using Sun's X server (the one under openwin), this was because
the X11R6.4 server had lots of font problems and you can't use a lot of
the sun tools because the X11R6 server doesn't start a postscript server.
With these to things combined it does work, it has also finally finished
building on my sparc II (the only one with SunOs 4.1.4 left) and it works
fine if I start it remotelly. So my first suggestion would be to use the
sun X server and see if it happens again. And trust me you won't notice
much of a performance hit since sun just took the X11r6 server and then
put there hardware specific stuff into it.
Hope this helps, or at least gives you an idea.
Brad
On 18 Jun 1998, Paul D. Smith wrote:
> I've been having a conversation with JWZ about a problem I'm seeing with
> the latest xscreensaver (2.21) on my SunOS 4.1.4 system at work, running
> X11R6.3 (fix2)--note: _not_ openwindows.
>
> Note I donn't have this problem with the previous version of
> xscreensaver I was using (2.07).
>
> However, I _ALSO_ don't have this problem with other window managers,
> like mwm, just with fvwm2 (2.0.46).
>
> However however, I don't have this problem on fvwm2 on my Linux box at
> home, which is exactly the same code (I ftp'd it down from my SunOS box
> and compiled it myself).
>
> Both of my systems are using 8-bit displays (my Linux box has a 2M
> graphics card but I run it at 1152x900 to match my Sun at work).
>
> What happens is that the colormaps get screwed up... the _SECOND_ time
> xscreensaver activates.
>
> I do this:
>
> $ xscreensaver &
> $ xscreensaver-command -next
>
> and it looks fine. Even if I let the graphics hack cycle, it works
> fine. Now I hit a key to deactive the screensaver, and I type:
>
> $ xscreensaver-command -next
>
> again, and this time the colormap is hosed: the background is white
> instead of black and the colors are all wrong. If I stop/restart the
> xscreensaver process, then it works again... the first time.
>
> Note the xscreensaver man page has this to say about a very
> similar-sounding problem with twm:
>
> TWM and Colormaps
> The installColormap option doesn't work very well with the
> twm(1) window manager and its descendants.
>
> There is a race condition between the screensaver and this
> window manager, which can result in the screensaver's colormap
> not getting installed properly, meaning the graphics hacks
> will appear in essentially random colors. (If the screen goes
> white instead of black, this is probably why.)
>
> The mwm(1) and olwm(1) window managers don't seem to have this
> problem. The race condition exists because X apparently does
> not provide a way for an OverrideRedirect window to have its
> own colormap, short of grabbing the server (which is neither a
> good idea, nor really possible with the current design.) What
> happens is that, as soon as the screensaver installs its
> colormap, twm responds to the ColormapNotify event that is
> generated by re-instaling the default colormap. Apparently,
> twm doesn't always do this; it seems to do it regularly if the
> screensaver is activated from a menu item, but seems to not do
> it if the screensaver comes on of its own volition, or is
> activated from another console.
>
> Note if I start xscreensaver with the -no-install option, so it doesn't
> install a colormap, it doesn't behave this way.
>
> Does anyone have any thoughts or ideas about what might be behind this
> problem, and how it might be fixed? Where, exactly, is the bug?
>
> --
> -------------------------------------------------------------------------------
> Paul D. Smith <psmith_at_baynetworks.com> Network Management Development
> "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
> -------------------------------------------------------------------------------
> These are my opinions--Bay Networks takes no responsibility for them.
> --
> Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
> To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
> message to majordomo_at_hpc.uh.edu.
> To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
>
--- There are two kinds of knowledge, you either know the answer or
you know where to find it
-Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri Jun 19 1998 - 06:08:53 BST