Post by Peter A. B » Mon, 21 Jun 2010 09:39:01

I have been using mwm for over 20 years. I just installed Ubuntu 10.4 on my
laptop and now when I press Alt-button1 in a window to raise the window
(defined in my .mwmrc file), mwm locks up and only allows input into the window
where I performed the Alt-button1. I have to kill mwm and restart it to make it
work again. I have no problems on Ubuntu 8.4 and 9.10. Is anyone else having
this problem? Can anyone suggest what's going wrong? I've tried everything to
make it work, including building and installing the latest and older versions
of open-motif. I really don't want to switch window managers, as I love the
simplicity of mwm. HELP!!!


Post by Russell Sh » Tue, 22 Jun 2010 18:20:31




Post by Chris Sore » Sat, 26 Jun 2010 15:59:17

What is the exact syntax of the line in your ~/.mwmrc?

I too am still an mwm user; nice to know there's more than one of
us... ;)


Post by pabuh » Sat, 26 Jun 2010 20:54:53

n article < XXXX@XXXXX.COM >,
Russell Shaw < XXXX@XXXXX.COM > wrote:

I did ask and it has moved on to this stage (see below). I don't know when the
patch will appear in distros. It appears to be have been a reasonably major bug
and many at xorg were glad it was found.

I'm pressing to my next problem with a bad interaction between mwm and
arcoread. I'll keep people here informed if I make any progress.


Date: Fri, 25 Jun 2010 09:48:10 +1000
From: Peter Hutterer < XXXX@XXXXX.COM >
To: "X.Org Devel List" < XXXX@XXXXX.COM >
Cc: "Peter A. Buhr" < XXXX@XXXXX.COM >,
Keith Packard < XXXX@XXXXX.COM >,
Daniel Stone < XXXX@XXXXX.COM >
Subject: [PATCH] Revert "dix: use the event mask of the grab for
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Behaviour of earlier X servers was to deliver the ButtonPress event
unconditionally, regardless of the actual event mask being set. Thus, a
GrabButton event will always deliver the button press event, a GrabKey
always the key press event, etc. Same goes for XI and XI2.

Reproducible with a simple client requesting a button grab in the form of:
XGrabButton(dpy, AnyButton, AnyModifier, win, True, ButtonReleaseMask,
GrabModeAsync, GrabModeAsync, None, None);

On servers before MPX/XI2, the client will receive a button press and
release event. On current servers, the client receives only the release.
Clients that expect the press event to be delivered unconditionally may
leave the user with a stuck grab.

XTS test results for XGrabButton are identical with and without this patch.

This reverts commit 48585bd1e3e98db0f3df1ecc68022510216e00cc.



Signed-off-by: Peter Hutterer < XXXX@XXXXX.COM >
dix/events.c | 52 ++--------------------------------------------------
1 files changed, 2 insertions(+), 50 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index ae9847c..e1c3d0a 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -3420,7 +3420,6 @@ CheckPassiveGrabsOnWindow(
DeviceIntPtr gdev;
XkbSrvInfoPtr xkbi = NULL;
- Mask mask = 0;

gdev= grab->modifierDevice;
if (grab->grabtype == GRABTYPE_CORE)
@@ -3535,9 +3534,6 @@ CheckPassiveGrabsOnWindow(
xE = &core;
count = 1;
- mask = grab->eventMask;
- if (grab->ownerEvents)
- mask |= pWin->eventMask;
} else if (match & XI2_MATCH)
rc = EventToXI2((InternalEvent*)event, &xE);
@@ -3549,34 +3545,6 @@ CheckPassiveGrabsOnWindow(
count = 1;
- /* FIXME: EventToXI2 returns NULL for enter events, so
- * dereferencing the event is bad. Internal event types are
- * aligned with core events, so the else clause is valid.
- * long-term we should use internal events for enter/focus
- * as well */
- if (xE)
- mask = grab->xi2mask[device->id][((xGenericEvent*)xE)->evtype/8];
- else if (event->type == XI_Enter || event->type == XI_FocusIn)
- mask = grab->


Post by Aaron W. H » Sun, 27 Jun 2010 02:56:28

I wonder how many there are? I still use it on and off as one of my
preferred window managers.

Aaron W. Hsu


Post by Aaron W. H » Sun, 27 Jun 2010 10:27:42

Hey Peter,

Thanks for this...

XXXX@XXXXX.COM (Peter A. Buhr) writes:

I just thought I would let you know that this really saved me! I just
moved back to using mwm from some tests with another window manager, and
I recently upgraded my system, too. As it turns out, this bug was
triggered almost as soon as I started to do any work with more than one
window in Mwm and it would freeze up my entire machine. I applied the
patch to my particular distributions version, and now things are
working like a charm. Thanks a bunch! I'm glad that the answer was
posted so close to when I needed it or I may never have found it.

Aaron W. Hsu