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.
Received on Thu Jun 18 1998 - 16:12:03 BST