Subject: Multi-headed display: patches and questions

From: Mark Rainford <[email-masked]>
Date: Thu, 10 Feb 2000 11:53:43 +0000

Dear fvwm-workers

Here are some simple patches to a recent CVS version, and some
questions about fvwm2 on multiple-screens (apologies for the
length).

The attached patchefile contains one simple bugfix to the macro
expansion of $v, and two unrelated (possibly less pallatable) changes
to help on a multi-screen display:

*       use display_name and screen_number in the restart_state_file
        name - avoids conflict in $HOME with the same user on many
        displays/screens

*       fvwm_msg() reports screen number (eg. [FVWM.0]) on
        multi-headed displays, no change for single screen display -
        this distinguishes messages from different invocations of fvwm.

I have been looking at the murky area of fvwm on multiple screens of
the same display: I get the impression that not many fvwm users have
multiple heads (eyes, ears, legs maybe, but not heads :-)

As the manual page says, when fvmw starts on a multi-headed display it
forks a copy of itself so there is one process per screen. The
first one is known to all by the "int master_pid" variable.

I don't use a session manager, so I see the following drawbacks (unless
I've mis-understood how this stuff works):

1. The Quit command is not distributed:

*       Quit in the master only quits that guy. The
        other fvwm's don't find out until the Xserver quits or the
        Xsession pursues a fanatical client clean-up.

*       Quit in a non-master quits that guy after it
        has sent SIGTERM to the master (which also quits). The other
        fvwm's again only find out later (yes ... we really do run a
        three headed display in our control room, and may go up to 6
        :-)

2. The Restart command is not distributed: it affects just the one
process, but that process forks new fvwm2s for each screen. They exit
on finding an ICCC2 WM already present.

3. Contrary to the manual, the "-restore state_file" option is not used
in the Restart function. Instead the same state_file name is used for
all screens on all displays - which can be bad, hence the patch. The
-restore option removes the state_file (not mentioned in the manual),
which is a disincentive for using -restore on the command line.

It seems to me we'd be a whole lot better off if Quit and Restart
treated the whole display by default, possibly affecting only one
screen as an option.  I can think of three alternative solutions:

(A) Use SIGTERM/USR1 to distribute Quit/Restart by sending it to the
whole process group rather than just one process - works on Solaris, but
is is portable? It would also require the Exec command to insulate the
forked process from SIGUSR1, otherwise xterm(1)s started from root menu
would vanish when you restarted the WM.

(B) Use pipes to distribute Quit/Restart from any to the master and
from there to all. Hey, that opens the door for Style distribution too
:-)

(C) Use one fvwm2 process to manage all the screens. I believe this
could be done by reworking the global use of the screen_info variable
"Scr" so that: (1) Scr is always passed as an argument to functions
which use it, (2) main creates a "Scr" for each screen, probably as an
array where ScrArray[0] is screen zero - the array could remain global
so that functions which can't manage (1) can fetch their Scr if they
know their screen number.

I suspect (A) would fall foul of too many portability issues, (C) is
the most technically correct, but not as easy or as quick as (B) to
implement. I'd like to do something along these lines, but am I going
about it the wrong way? what impact does Session Management have?

The patches to 2.3.14 from the CVS tree are:

fvwm/functions.c        bugfix in expansion of $v (version) macro
fvwm/fvwm.c             name restart state file after display and screen
fvwm/misc.c             indicate screen number in fvwm_msg() when >1
screen

-- 

Regards,  Mark.

Index: functions.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/functions.c,v
retrieving revision 1.123
diff -u -b -B -r1.123 functions.c
--- functions.c	2000/02/05 20:04:29	1.123
+++ functions.c	2000/02/10 11:38:39
@@ -583,6 +583,7 @@
 	break;
       case 'v':
 	sprintf(&out[j], "%s", (Fvwm_VersionInfo) ? Fvwm_VersionInfo : "");
+	j += strlen(&out[j]);
 	i++;
 	break;
       case '$':
Index: fvwm.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.200
diff -u -b -B -r1.200 fvwm.c
--- fvwm.c	2000/01/31 20:26:24	1.200
+++ fvwm.c	2000/02/10 11:38:40
@@ -138,7 +138,7 @@
 int g_argc;
 
 char *state_filename = NULL;
-char *restart_state_filename = NULL;  /* $HOME/.fs-restart */
+char restart_state_filename[1024];  /* $HOME/.fs-restart */
 
 /* assorted gray bitmaps for decorative borders */
 #define g_width 2
@@ -393,11 +393,17 @@
         Scr.screen = myscreen;
         Scr.NumberOfScreens = ScreenCount(dpy);
 
+        /* generate fvwm restart state preservation filename for this screen */
+        sprintf( restart_state_filename , "%s/.fs-restart-%s" , user_home_dir , message);
+
         break;
       }
     }
   }
 
+  /* generate fvwm restart state preservation filename for this screen */
+  sprintf( restart_state_filename , "%s/.fs-restart-%s" , user_home_dir , XDisplayString(dpy));
+
   x_fd = XConnectionNumber(dpy);
   fd_width = GetFdWidth();
 
@@ -588,10 +594,9 @@
     }
   }
 
-  restart_state_filename =
-    strdup(CatString2(user_home_dir, "/.fs-restart"));
   if (!state_filename && Restarting)
     state_filename = restart_state_filename;
+  DBUG("main","state_filename = %s", state_filename);
 
   /*
      This should be done early enough to have the window states loaded
Index: misc.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/misc.c,v
retrieving revision 1.84
diff -u -b -B -r1.84 misc.c
--- misc.c	2000/01/25 14:38:57	1.84
+++ misc.c	2000/02/10 11:38:40
@@ -313,7 +313,14 @@
 
   va_start(args,msg);
 
+  if ( Scr.NumberOfScreens > 1 )
+  {
+    fprintf(stderr,"[FVWM.%d][%s]: %s ",Scr.screen,id,typestr);
+  }
+  else
+  {
   fprintf(stderr,"[FVWM][%s]: %s ",id,typestr);
+  }
   vfprintf(stderr, msg, args);
   fprintf(stderr,"\n");

---

From: Tim Phipps <[email-masked]>
Date: Thu, 10 Feb 2000 13:36:00 +0000

Mark Rainford wrote:
> (A) Use SIGTERM/USR1
> (B) Use pipes to distribute Quit/Restart
> (C) Use one fvwm2 process to manage all the screens.

> implement.

I don't think (C) is the way to go, there are too many issues like:

How do modules work? Does the StartFunction get repeated on each screen?
What does KillModule do? What does Next/Prev consider?

If the answer to all these is that each screen behaves independently of
all the others then there is no difference between one fvwm managing all
screens and an fvwm for each screen.

I would favour making fvwm _not_ do anything on multiscreen setups apart
from maybe forking of a copy per screen at start up. After that they
should run without any linkage. If you want a to restart all fvwm's then
you can send the USR1 signal to all of them (use kfork, maim or
killall). HUP, INT, QUIT & TERM all cause fvwm to exit, I'm not sure
which propogate through to children). Communication between fvwm's could
be done with FvwmCommand (I think this works already).

I think this is pretty well what we have at the moment except that the
first fvwm remains as the parent of the others and may propogate signals
on to them.

Cheers,
Tim.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 10 Feb 2000 14:49:40 +0100

> questions about fvwm2 on multiple-screens (apologies for the

Can someone else please check and apply these patches?

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 10 Feb 2000 15:51:42 +0200

On 10 Feb 2000 11:53:43 +0000, Mark Rainford wrote:
> expansion of $v

good.

>         name - avoids conflict in $HOME with the same user on many

I don't feel this patch by itself fixes something.
It should be fixed in a whole. So I am not applying this part for now.

>         this distinguishes messages from different invocations of fvwm.

ok.

> multiple heads (eyes, ears, legs maybe, but not heads :-)

I am not competent here, so I am skipping the part about multiple heads.

> on finding an ICCC2 WM already present.

Right, this should be a problem for multiple heads.
I tried to fix this some time ago (search for '/* single = True; */'),
but didn't succeed to move this to earlier stages of main() without
breaking something else.

> which is a disincentive for using -restore on the command line.

-restore like -clientId were designed for internal use by a SM support
code. -restore is not used for Restart without SM. man page probably
should be more clear about this.

The state file used for Restart without SM is really transient (i.e.
should be removed after the usage).

> diff -u -b -B -r1.123 functions.c

Please remove '-b -B' from diff in ~/.cvsrc, it was a bad advice in
cvs.html once.

Regards,
Mikhael.

---

From: Mark Rainford <[email-masked]>
Date: Thu, 10 Feb 2000 16:18:40 +0000

Tim Phipps wrote:
> ... 

Hmm, complicated, unless - as you say - they are independent as if in
separate
fvwm processes.

> ...
> If you want a to restart all fvwm's then
> which propogate through to children).

For us this is too broad: I can be logged in at more that one display
but I don't necessarily want all of them to Quit together. Also, we have
role-based logins (long before SunMS ever came up with the term) - a
"Shift Technician" (Fred) logs in as user "ST" at his duty post, while
Bert logs in as "ST" at a another X-terminal in another room on the same
machine. SIGTERM/USR1 interraction would be bad.

> Communication between fvwm's could

Yes, I wondered about FvwmCommand: I'll see if I can cobble together a
Quit/Restart distribution.

Thanks.
-- 

Regards,  Mark.

---

From: Mark Rainford <[email-masked]>
Date: Thu, 10 Feb 2000 16:32:49 +0000

> It should be fixed in a whole. So I am not applying this part for now.

Can I plead the case for this: first it does no harm, second it
positively helps me today: if I restart both fvwm process for my twin
screen display then they both try to write the same file !

> but didn't succeed to move this to earlier stages of main() without

I guess somehow inserting "-s" into the argv of the recently forked
child fvwm process and setting "single" would do the trick .. I'll look.

> should be removed after the usage).

Okay.

> Please remove '-b -B' from diff in ~/.cvsrc, it was a bad advice in

Done. Thanks.
-- 

Regards,  Mark.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 10 Feb 2000 20:16:53 +0200

> screen display then they both try to write the same file !

Only if you restart them simultaneously.

I will try to verify all possible cases with the single/multiple head and
inside a session manager - when these files should be used, when removed -
and then probably apply the fix.

> child fvwm process and setting "single" would do the trick .. I'll look.

Maybe. Be careful here. You will probably want to insert "-s" for the main
process too for simmetry.

Regards,
Mikhael.