Subject: FVWM: xscreensaver colormap bug?

From: [email-masked] (Paul D. Smith)
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 <[email-masked]>         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 [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 18 Jun 1998 22:29:34 -0400

PS. Jamie asks you CC him on any interesting suppositions you might
    have about this problem; [email-masked]

    Thx.

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 19 Jun 1998 07:08:18 -0400 (EDT)

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

> problem, and how it might be fixed?  Where, exactly, is the bug?

--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: Jamie Zawinski <[email-masked]>
Date: Fri, 19 Jun 1998 10:36:32 -0700

> put there hardware specific stuff into it.

Well, to me this sounds a lot more like a race condition than a server
problem (changing servers changes the timing of events.)

Perhaps it would shed some light if someone would explain exactly the
conditions under which fvwm installs a colormap.

-- 
Jamie Zawinski         http://people.netscape.com/jwz/      about:jwz