Quick synopsis: With motif applications (my tests were done using x11-libs/openmotif-2.3.2 and dev-util/ddd-3.3.12-r1), depending on how exactly the popup menus are implemented, simply opening a popup menu may steal all your X input and not give it back until you kill the offending app. What's really neat about 'ddd' as a test case is that it seems to have popups implemented slightly differently in each of its display areas, with slightly different behaviours in each one: (1) In the "Data Window", every right-click triggers the problem: The mouse cursor changes, mouse button and keyboard input is grabbed, but the popup menu never shows, and the inputs are never un-grabbed. The mouse cursor can still move about the screen, and window contents are still refreshed. Killing 'ddd' from a terminal will ungrab the inputs. (2) In the "Source Code Window" or "Machine Code Window", every right-click works properly, popups are displayed and dismissed as expected, any number of times, with no issues. (3) In the "GDB Console Window", the *first* right-click works normally, popup displays, and can be cleared properly. The *second* right-click causes the same problem as in (1). (4) I have tested the exact same ddd/openMotif X client (amd64) against 4 different X servers now, with the following results: XMing-6.9.0.31(WinXP 32-bit): All popups function as expected, no problems xorg-server-1.6.4(Gentoo x86): All popups function as expected, no problems xorg-server-1.7.3(Gentoo x86): Problems as explained above xorg-server-1.7.3(Gentoo amd64): Problems as explained above
Here are my thoughts (yes, I do think every now and then ;) ) : - it's not really clear (yet) who's at fault here, it could very well be motif - between 1.6 and 1.7, the whole input subsystem was completely overhauled. So there are 2 possibilities : - the server changed input semantics from the X protocol spec and broke one of the lesser used options - motif was relying (unknowingly) on a broken X server feature which was straightened out during the cleanup. From what I can see, it could be either possibility. The best way to get to the bottom of this bug is to use xtrace or tcpdump to listen in on the core protocol exchange to see what's really going on. In any case, let's track the bug upstream, there isn't much we'll be able to do here. Thanks
(In reply to comment #1) > - it's not really clear (yet) who's at fault here, it could very well be motif Oh gosh I hope it's not motif... I wonder how many propretary motif-based apps there are out there that would just stop working forever! (trace32 by Lauterbach is the one I'm presently worried about, which led me down this path in the first place) > The best way to get to the > bottom of this bug is to use xtrace or tcpdump to listen in on the core > protocol exchange to see what's really going on. Sounds like a fun idea! I'll give that a try ;) > In any case, let's track the bug upstream, there isn't much we'll be able to do > here. Agreed, just thought I should make note of this in our system in case some day you want to stabilize 1.7 :)
The patch from upstream in the bug referenced above fixes the issue for me when I apply it to Gentoo's x11-base/xorg-server-1.7.3.901 Direct link to the patch: http://bugs.freedesktop.org/attachment.cgi?id=32100 Any interest in my ebuild I used to apply this patch? Pretty trivial to do, just download that patch and add it to $PATCHES but I'd be happy to make attachments here or check in to CVS if you like.
I allowed Jim to patch it in main tree. If noone reports it as borked I recommend we nominate it for 1.7.4. (so far it works on my boxes)
(In reply to comment #4) > If noone reports it as borked I recommend we nominate it for 1.7.4. > (so far it works on my boxes) It has to go to master before we can nominate it for the 1.7 branch.
It is now in the official xorg/xserver master branch: http://cgit.freedesktop.org/xorg/xserver/commit/?id=cf72b5437d2d620521279077a29c5df6d0fbb576
Though the actual "official" fix is considerably different than the one I previously checked in from the upstream bug. I haven't tested it yet.
A quick test implies the new fix works just as well as the previous one. Is it worth revbumping to xorg-server-1.7.5-r1 just to change this patch, or will it just be on the next actual xorg-server bump?
Fix included in 1.7.5.901
This fix apparently breaks other WMs... let's take a closer look at this. See upstream bug report. Cheers
(In reply to comment #10) > This fix apparently breaks other WMs... let's take a closer look at this. See > upstream bug report. Yay, when I tested the new version, I just tested the bug reported here: I ran ddd in Xephyr with no WM, assuming Upstream had already tested the basics... Apparently that was not the case. Current situation: x11-base/xorg-server-1.7.5 still has the older patch which fixes the issue outlined in this bug and does *not* break WMs x11-base/xorg-server-1.7.5.901 is broken. I'd suggest masking 1.7.5.901 for now until Upstream fixes this issue for real.
(In reply to comment #11) > I'd suggest masking 1.7.5.901 for now until Upstream fixes this issue for real. Masked.
1.7.6 works fine.
Hi. I'm not sure if my problems are related to this bug, but here it goes: When I click on a window, that window "grabs" the mouse events. So I cannot select any other windows. Unless I right click anywhere on the previously selected window, the other windows get the mouse events. Tested with KWin and TWM. xorg-server 1.7.6 and 1.7.7 evdev - 2.3.* and 2.4
