FVWM: xscreensaver colormap bug?

From: Paul D. Smith <psmith_at_BayNetworks.COM>
Date: 18 Jun 1998 16:50:56 -0400

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

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:38:01 BST