Re: fvwm starts when other window manager is already activeOrganization:
On Sat, Jan 28, 2006 at 05:47:34PM +0100, Viktor Griph wrote:
On Sat, 28 Jan 2006, Dominik Vogt wrote:
On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote:
On Thu, 22 Sep 2005, Manoj Srivastava wrote:
[snip]
are unable to detect other window managers.(Tested with ratpoison and
woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and
enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm,
making this almost every other window manager other than fvwm
itself).
[anip]
I've done some tests and belive that this bug is due to a change in X with
XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch,
and all have the bug. However I'm sure that the bug was not present when I
used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something
else that has changed since then. The bug is however not present in
2.4.19, so it must be soemthing that has changed in the early 2.5.x
versions, which I weren't able to compile now.
No, the only change since at least 2.3.0 was introducing the
-replace option. We haven't touched this code in *ages*.
Have you not?
You're right. I was under the impression we were talking about
the code that detects ICCCM2 compliant window managers because of
the sheer size of the window manager list. It looks like nobody
bothers to set the corresponding property in any window manager.
$ cvs log -r1.290 -N fvwm.c
revision 1.290
date: 2002/03/17 17:34:15; author: domivogt; state: Exp; lines: +7 -10
* Replaced Xsync with XFlush almost everywhere. Note: it's rarely
necessary to use XSync. XFlush usually suffices and is faster.
* More work on frame layout.
* Some general clean up.
The relevant part of the cvs diff -r 1.289 -r 1.290 fvwm.c:
Index: fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.289
retrieving revision 1.290
diff -u -r1.289 -r1.290
--- fvwm.c 15 Mar 2002 17:02:25 - 1.289
+++ fvwm.c 17 Mar 2002 17:34:15 - 1.290
@@ -557,21 +559,21 @@
CWEventMask | CWOverrideRedirect |
CWColormap
| CWBackPixmap | CWBorderPixel,
attributes);
XMapWindow(dpy, Scr.NoFocusWin);
-
SetMWM_INFO(Scr.NoFocusWin);
FOCUS_SET(Scr.NoFocusWin);
- XSync(dpy, 0);
+ frame_init();
+ XFlush(dpy);
if(debugging)
{
sync_server(1);
}
- SetupICCCM2 (replace_wm);
+ SetupICCCM2(replace_wm);
XSetErrorHandler(CatchRedirectError);
XSetIOErrorHandler(CatchFatal);
XSelectInput(dpy, Scr.Root, XEVMASK_ROOTW);
- XSync(dpy, 0);
+ XFlush(dpy);
XSetErrorHandler(FvwmErrorHandler);
I think that last XSync really should be there since, if I understand the
test correctly it relies on an error to be generated if a window manager
already exists, and XSync does wait until all requests are processed, and
the errors handled, but XFlush just flushes the output buffer.
Actually an error *is* generated, but it is processed by the wrong
error handler (i.e. by FvwmErrorHandler). It's not enough to put
an XSync after XSelect input, there should also be one *before*
XSetErrorHandler to prevent that other errors are mistaken as a
clue that another wm is running. I'll commit a patch.
I guess
it's up to the threadin model of the X-server weather or not any errors
generated by recently flushed requests are handled before or after the
request to change error handler to FvwmErrorHandler is processed.
No, not at all. XSetErrorHandler is processed locally in Xlib
without any protocol requests to the X server, so only the kernel
scheduling algorithm has some influence on this.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: fvwm starts when other window manager is already activeOrganization:
On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. /Viktor
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, 28 Jan 2006, Bernhard R. Link wrote: * Viktor Griph [EMAIL PROTECTED] [060128 14:36]: I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. I'm seeing the bug here with the Debian sarge version of XFree86 namely 4.3.0.dfsg.1-14sarge1. I do not know if it contain any patches taken from Xorg, though. Hochachtungsvoll, Bernhard R. Link Well, I really don't know about that. thinking about it the only x-server I'm certain it has worked with is a version of Xsun on solaris 2.8. Looking at the fvwm code I believe it might be that an XSync has been changed to an XFlush in the startup code before changing the errorhandler from the one that traps running WMs to the normal fvwm error handler. But since I'm not sure exactly how this WM-trapping is supposed to work I leave to someone else to decide if changing it back to XSync is correct. /Viktor
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote: On Thu, 22 Sep 2005, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Recent versions of fvwm, while being able to detect other versions of fvwm currently running: -- __ fvwm [FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running, try -replace -- are unable to detect other window managers.(Tested with ratpoison and woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm, making this almost every other window manager other than fvwm itself). Older versions of fvwm used to display this warning: -- [FVWM][CatchRedirectError]: ERROR another WM is running -- But the newer ones do not, for reasons I could not debug. This is a regression, and the other window managers are able to detect fvwm and refuse to run. Please see http://bugs.debian.org/328621 for details. manoj I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. No, the only change since at least 2.3.0 was introducing the -replace option. We haven't touched this code in *ages*. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: fvwm starts when other window manager is already activeOrganization:
On Sat, 28 Jan 2006, Dominik Vogt wrote:
On Sat, Jan 28, 2006 at 02:20:13PM +0100, Viktor Griph wrote:
On Thu, 22 Sep 2005, Manoj Srivastava wrote:
Hi,
[Please retain the CC to [EMAIL PROTECTED]
so that the Debian BTS has a record of your input]
This was reported by a Debian user.
Recent versions of fvwm, while being able to detect other
versions of fvwm currently running:
--
__ fvwm
[FVWM][SetupICCCM2]: ERROR another ICCCM 2.0 compliant WM is running,
try -replace
--
are unable to detect other window managers.(Tested with ratpoison and
woody's icewm, sarge's icewm, icewm-gnome, wm2, qvwm and
enlightment. Also fluxbox, blackbox, ion3, xfwm4, wmaker and twm,
making this almost every other window manager other than fvwm
itself).
Older versions of fvwm used to display this warning:
--
[FVWM][CatchRedirectError]: ERROR another WM is running
--
But the newer ones do not, for reasons I could not debug. This
is a regression, and the other window managers are able to detect
fvwm and refuse to run.
Please see http://bugs.debian.org/328621 for details.
manoj
I've done some tests and belive that this bug is due to a change in X with
XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch,
and all have the bug. However I'm sure that the bug was not present when I
used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something
else that has changed since then. The bug is however not present in
2.4.19, so it must be soemthing that has changed in the early 2.5.x
versions, which I weren't able to compile now.
No, the only change since at least 2.3.0 was introducing the
-replace option. We haven't touched this code in *ages*.
Have you not?
$ cvs log -r1.290 -N fvwm.c
revision 1.290
date: 2002/03/17 17:34:15; author: domivogt; state: Exp; lines: +7 -10
* Replaced Xsync with XFlush almost everywhere. Note: it's rarely
necessary to use XSync. XFlush usually suffices and is faster.
* More work on frame layout.
* Some general clean up.
The relevant part of the cvs diff -r 1.289 -r 1.290 fvwm.c:
Index: fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.289
retrieving revision 1.290
diff -u -r1.289 -r1.290
--- fvwm.c 15 Mar 2002 17:02:25 - 1.289
+++ fvwm.c 17 Mar 2002 17:34:15 - 1.290
@@ -557,21 +559,21 @@
CWEventMask | CWOverrideRedirect |
CWColormap
| CWBackPixmap | CWBorderPixel,
attributes);
XMapWindow(dpy, Scr.NoFocusWin);
-
SetMWM_INFO(Scr.NoFocusWin);
FOCUS_SET(Scr.NoFocusWin);
- XSync(dpy, 0);
+ frame_init();
+ XFlush(dpy);
if(debugging)
{
sync_server(1);
}
- SetupICCCM2 (replace_wm);
+ SetupICCCM2(replace_wm);
XSetErrorHandler(CatchRedirectError);
XSetIOErrorHandler(CatchFatal);
XSelectInput(dpy, Scr.Root, XEVMASK_ROOTW);
- XSync(dpy, 0);
+ XFlush(dpy);
XSetErrorHandler(FvwmErrorHandler);
I think that last XSync really should be there since, if I understand the
test correctly it relies on an error to be generated if a window manager
already exists, and XSync does wait until all requests are processed, and
the errors handled, but XFlush just flushes the output buffer. I guess
it's up to the threadin model of the X-server weather or not any errors
generated by recently flushed requests are handled before or after the
request to change error handler to FvwmErrorHandler is processed.
/Viktor
Re: fvwm starts when other window manager is already activeOrganization: Manoj Srivastava's Home
* Viktor Griph [EMAIL PROTECTED] [060128 16:48]: Well, I really don't know about that. thinking about it the only x-server I'm certain it has worked with is a version of Xsun on solaris 2.8. Looking at the fvwm code I believe it might be that an XSync has been changed to an XFlush in the startup code before changing the errorhandler from the one that traps running WMs to the normal fvwm error handler. But since I'm not sure exactly how this WM-trapping is supposed to work I leave to someone else to decide if changing it back to XSync is correct. I really think that is the problem (XSync vs XFlush). Looking into the libX11 code XFlush only writes all pending things to the X-server. Unless writing more would block[1] it does not read anything. Thus it cannot receive any Error notification from the server thus CatchRedirectError is never called. When I replace the XFlush with an XSync, the message from the CatchRedirectError handler is shown and fvwm termiantes correctly if any other window manager is running. Changing XSync back to XFlush and adding some diagnostics to FvwmErrorHandler I see it receiving a BadAccess(10) Error for a X_ChangeWindowAttributes(2) request. And XSelectInput simply sends a ChangeWindowAttributes request for the specified window and EXEVMASK_ROOTW contains SubstructureRedirectMask (which fits to the name of the CatchRedirectError handler) and xspec/proto.txt tells: | Multiple clients can select input on the same window; their | event-masks are disjoint. When an event is generated, it | will be reported to all interested clients. However, only | one client at a time can select for SubstructureRedirect, | only one client at a time can select for ResizeRedirect, and | only one client at a time can select for ButtonPress. An | attempt to violate these restrictions results in an Access | error. Hochachtungsvoll, Bernhard R. Link [1] This could be the cause of it working earlier or under different operating systems, the buffers for unix sockets or tcp connections might have increased.
Re: fvwm starts when other window manager is already activeOrganization: Manoj Srivastava's Home
* Viktor Griph [EMAIL PROTECTED] [060128 14:36]: I've done some tests and belive that this bug is due to a change in X with XOrg 6.8. I've tested fvwm 2.5.16, 2.5.10 and 2.5.4 from the 2.5.x branch, and all have the bug. However I'm sure that the bug was not present when I used 2.5.4 (and probably not 2.5.10) actively. Thus it must be something else that has changed since then. The bug is however not present in 2.4.19, so it must be soemthing that has changed in the early 2.5.x versions, which I weren't able to compile now. I'm seeing the bug here with the Debian sarge version of XFree86 namely 4.3.0.dfsg.1-14sarge1. I do not know if it contain any patches taken from Xorg, though. Hochachtungsvoll, Bernhard R. Link
