Subject: RE: FVWM: DISPLAY changes on restart

From: "Dameron, Gregg" <[email-masked]>
Date: Thu, 11 Apr 2002 18:42:06 -0600

> > Perhaps a better question is this:  Is it reasonable for a window
manager to
> > set DISPLAY if it subverts the value it inherits from the session
manager?
> 
> Probably yes. There are several cases, $DISPLAY is initially set or not,
> -d is given or not. I think it is ok to set $DISPLAY to what X says after
> all given input (if any) is processed.
> 

I'm not so sure.  If the session manager parents fvwm2 with a legitimate
$DISPLAY value already set (like :0.1), ignoring it and setting $DISPLAY
anyway seems risky, especially since Xlib _may_ tell fvwm2 that display is
"unix:0.1".  It seems to me _any_ window manager should attempt to use the
display handed to it if possible (either inherited through $DISPLAY or
hardwired via command line option), to keep the wm in sync with the session
manager's other children.

> 
> Just for a curious, what is your setup?
> 
> Real session manager and multi-screen display?
> 
> How do you restart, using which command on which screen?
> 

I am running a two-headed display under Solaris 7's dtsession (not
Xinerama).  At login, twin instances of the default window manager are
started.  I bring up an xterm on the right screen (:0.1) and kill the
right-side wm instance.  In that same window, I start fvwm2 manually:

  % /<path>/fvwm2 -s -f /<path>/<config_file>

I am able to recreate the problem with this minimalist <config_file>:

  ModulePath /<path>/modules:+
  AddToFunc StartFunction
  + I Echo $[DISPLAY]
  + I FvwmTaskBar
  + I FvwmCommandS

On startup, I always see in the xterm:

  [FVWM.1][Echo]:  :0.1

I restart using fvwm2's built-in root menu on the right screen.  Sometimes
on the first restart, I see the "wrong" answer:

  [FVWM.1][Echo]:  unix:0.1

Sometimes a few dozen restarts are required before I see it.  With my
"regular" (bigger) config file, only one or two restarts are required before
the problem occurs.

Gregg Dameron
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Mikhael Goikhman <[email-masked]>
Date: Sun, 14 Apr 2002 21:10:16 +0000

On 11 Apr 2002 18:42:06 -0600, Dameron, Gregg wrote:
> > > manager to set DISPLAY if it subverts the value it inherits from the
> > > session manager?
> > 
> "unix:0.1".

":0.1" and "unix:0.1" are different names for the same thing, so I see
nothing risky for X applications. If you want to use $DISPLAY as a part of
a file name you may handle this situation by stripping the leading "unix"
before using it in the file name.

> It seems to me _any_ window manager should attempt to use the

I don't know why X returns different strings in your situation, sorry.
It may be a problem in our implementation of SM, but I don't see it.

>   % /<path>/fvwm2 -s -f /<path>/<config_file>

Hmm, this is a bit strange way of starting fvwm. :)
Especially if dtsession is a session manager. Is it?

You may just use "save session" capability in dtsession and twin will not
be started on the next dtsession startup, instead FVWM will be started.
At least this is possible in xsm and gnome-session, I didn't use dtsession.

There may be problems because your setup is not trivial.
I don't know whether twin is session manager aware, i.e. supports XSMP.

> "regular" (bigger) config file, only one or two restarts are required before

I can only try to explain what happens when you do "Restart" when inside a
session manager. This is different from what happens without a session
manager. FVWM asks a session manager to start-me-if-I-exit using a given
command line that has all original parameters plus -s -d. This logic is in
session.c. Then FVWM exits and dtsession "re-starts" it as requested.

-d is constructed using XDisplayString(dpy), so the restarted instance
has -d parameter although the original one may not. This is needed for
your setup, so only the FVWM on the right screen is restarted although
the original command could be for all screens (i.e. no -s was specified).

if you run long ps (ps -w -w -w or similar) which -d parameter do you see,
"unix:0.1" or ":0.1"?

In any case, you may just strip the leading "unix" in file names to solve
your problem.

Regards,
Mikhael.

---

From: Gregg Dameron <[email-masked]>
Date: Tue, 16 Apr 2002 14:00:41 -0600

Mikhael Goikhman wrote:

> nothing risky for X applications.

Right.  The risk is to processes that are siblings of fvwm2 (other children of
the session manager), who (a) are not X-based, (b) inherited $DISPLAY from the
session manager, and (c) wish to talk to fvwm2 using FvwmCommand -f.  When fvwm2
has a different notion of $DISPLAY than its siblings, FvwmCommand won't work if
$DISPLAY is part of the FIFO's name.

> If you want to use $DISPLAY as a part of

Understood.  In fact, I went a step further - I've got a PipeRead script in my
config that detects a leading "unix", strips it out, then resets (SetEnv) DISPLAY
before running FvwmCommandS.

> Hmm, this is a bit strange way of starting fvwm. :)

Yes it is, but it's only temporary while I'm experimenting with fvwm2.  This
setup allows me to do a side-by-side compare between fvwm2 and the other wm
(which, BTW, is fvwm95).  Eventually I'll be starting fvwm2 on both screens at
login (using FAQ 2.2).

> Especially if dtsession is a session manager. Is it?

Yes (for CDE).

> if you run long ps (ps -w -w -w or similar) which -d parameter do you see,

Running fvwm2 by hand as I am doing, a restarted fvwm2 shares the same PID and
same argument list as when first started - no "-d" unless I started it that way.
I'll make a note to check it again when fvwm2 is truly parented by dtsession.

Thanks for your response.