Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you, Dokinik, for your assessment: > > How would you judge its behavior concerning stability and side effects: > > Would it be to risky to use it right away in a production system, aka > > "testing under wild life conditions"? > > The worst that can happen is that different windows aren't > accessible. Regarding stability, I'd say the patched code is how > it should have been from the start, but you never know what > strange and broken applications are around and how they react to > changes in the events before you just try it for a while. This > certainly needs testing. > > However, this patch only affects clients that do things like > iconifying or withdrawing their windows, i.e. the vast majority of > programs won't be affected, but you never know what closed source > programs until they break. So I will use the fixed version looking out for such a behavior of applications and report corresponding findings here. Thank you very much, Dominik, for taking care of that problem, and your profound analysis and comprehensive help. Greetings Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Mon, Nov 21, 2016 at 06:25:29PM +, Jürgen Hartmann wrote: > > It's really complicated, but let me try to explain what's going > > on, in case we need to understand why I made the current patch - > > at some time in the distant future. > > [Very thorough and enlightening explanation skipped.] > > > Duh. > > > > Obviously vmplayer cannot handle this strange situation and ends > > up with no window mapped. > > Thank you for this comprehensive explanation including references for further > reading (ICCCM2). > > > As far as I understand it, HandleUnmapNotify() is broken at least > > since the day in 1998 when the fvwm sources were moved to CVS. > > I've spent much time thinking about this, reading the ICCCM2 and > > the Xlib manuals, and now I'm convinced that HandleUnmapNotify() > > must never unmap the client window itself. (The *icon* window is > > a different story.) However, since there's no documentation about > > this bit of code, it's hard to guess whether there are or were > > really broken clients that needed this buggy window manager > > behaviour. Anyway, if there are such clients, they won't work on > > any modern window manager. > > > > Over the years there were several patches to fix problems caused > > by unmapping windows in HandleUnmapNotify, but none of us ever > > figured out the real bug for more than fifteen years. :-/ > > So this fix of yours really seems to be a big step. > > How would you judge its behavior concerning stability and side effects: > Would it be to risky to use it right away in a production system, aka > "testing under wild life conditions"? The worst that can happen is that different windows aren't accessible. Regarding stability, I'd say the patched code is how it should have been from the start, but you never know what strange and broken applications are around and how they react to changes in the events before you just try it for a while. This certainly needs testing. However, this patch only affects clients that do things like iconifying or withdrawing their windows, i.e. the vast majority of programs won't be affected, but you never know what closed source programs until they break. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> It's really complicated, but let me try to explain what's going > on, in case we need to understand why I made the current patch - > at some time in the distant future. [Very thorough and enlightening explanation skipped.] > Duh. > > Obviously vmplayer cannot handle this strange situation and ends > up with no window mapped. Thank you for this comprehensive explanation including references for further reading (ICCCM2). > As far as I understand it, HandleUnmapNotify() is broken at least > since the day in 1998 when the fvwm sources were moved to CVS. > I've spent much time thinking about this, reading the ICCCM2 and > the Xlib manuals, and now I'm convinced that HandleUnmapNotify() > must never unmap the client window itself. (The *icon* window is > a different story.) However, since there's no documentation about > this bit of code, it's hard to guess whether there are or were > really broken clients that needed this buggy window manager > behaviour. Anyway, if there are such clients, they won't work on > any modern window manager. > > Over the years there were several patches to fix problems caused > by unmapping windows in HandleUnmapNotify, but none of us ever > figured out the real bug for more than fifteen years. :-/ So this fix of yours really seems to be a big step. How would you judge its behavior concerning stability and side effects: Would it be to risky to use it right away in a production system, aka "testing under wild life conditions"? Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Mon, Nov 21, 2016 at 12:27:45AM +, Jürgen Hartmann wrote: > Concerning side effects, I can't say anything since I have no idea what > to look for. > > > Now, if I'd understand what (a) the patch in > > HandleMapRequestKeepRaised() is supposed to do, > > Which patch do you mean? Does the piece of code that you disable in events.c > origins from an earlier patch? Yes, it that piece may have been an attempt to fix the same or a similar bug with another application. It's really complicated, but let me try to explain what's going on, in case we need to understand why I made the current patch - at some time in the distant future. -- 1) Window managers have special powers in X. In the presence of a window manager, certain requests of the clients are "redirected" to the window manager for confirmation. In the case at hand, clients cannot map top level windows without the window manager's consent (i.e. the MapRequest event gets redirected to the window manager). The same is not true for unmapping. Clients can always unmap their windows; the window manager is just informed when that happens. 2) There is this old "Inter Client Communication Conventions Manual" version 2, that defines three distinct window states that any window manager should implement: normal, iconic and withdrawn. The latter means that neither the window nor its icon are visible. The ICCCM2 also describes how to get a window from each state into the other two states. 3) To withdraw a normal or iconic window, the client is supposed to first unmap the main window. As the window may not be mapped at that time, for example if its iconic, the window manager may not receive an UnmapNotify event for that. To make sure that the window manager gets it, the client is supposed to send a synthetic UnmapNotify event to the root window (the window manager always gets events for the root window). (This synthetic event contains the id of the unmapped window.) In response to this event, the window manager is supposed to write down that the window is now in withdrawn state, and unmap the *icon window* if its visible. 4) In HandleUnmapEvent() there was some code from the ancient past of fvwm, that - whenever fvwm received an UnmapNotify (that it did not trigger itself) - *it would unmap the window (that is was just told has already been unmapped*. I can only guess why this code was there, maybe the author thought that the client was asking for permission to unmap the window. 5) For some strange reason, when vmplayer wants to un-fullscreen a window, it requests the window manager to end fullscreen state, then withdraws the window as described above, and after that I lost interest in event debugging. Supposedly it maps the window again after that. ==> Putting it all together: * vmplayer requests end of fullscreen mode * vmplayer unmaps the window * vmplayer sends the synthetic event as described above * vmplayer maps the window again (which needs fvwm's consent). * fvwm receives the events generated by vmplayer * fvwm looks at the two UnmapNotify events it gets (one real and the syntehtic one) and calls XUnmapWindow. This generates another UnmapNotify event. * fvwm sees the MapRequest and generates the decorations for the window. * fvwm receives the UnmapNotify it generated itself, destroys the decorations and leaves the window unmapped. Duh. Obviously vmplayer cannot handle this strange situation and ends up with no window mapped. -- As far as I understand it, HandleUnmapNotify() is broken at least since the day in 1998 when the fvwm sources were moved to CVS. I've spent much time thinking about this, reading the ICCCM2 and the Xlib manuals, and now I'm convinced that HandleUnmapNotify() must never unmap the client window itself. (The *icon* window is a different story.) However, since there's no documentation about this bit of code, it's hard to guess whether there are or were really broken clients that needed this buggy window manager behaviour. Anyway, if there are such clients, they won't work on any modern window manager. Over the years there were several patches to fix problems caused by unmapping windows in HandleUnmapNotify, but none of us ever figured out the real bug for more than fifteen years. :-/ Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> > What would you propose to proceed? > > 1) Don't panic. ;) Truly a wise word... :) > 2) Try the attached patch. Done: It works great with respect to our issue. For Player and Workstation. Concerning side effects, I can't say anything since I have no idea what to look for. > Now, if I'd understand what (a) the patch in > HandleMapRequestKeepRaised() is supposed to do, Which patch do you mean? Does the piece of code that you disable in events.c origins from an earlier patch? > and (b) why > XUnmapWIndow() is called in HandleUnmapNotify(), I think I could > write a decent fix instead of jsut disabling the parts of the code > that cause trouble. I am really glad that you are willing to dig into this. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Sun, Nov 20, 2016 at 10:02:39PM +, Jürgen Hartmann wrote:
> > > What is the secret behind this move? How does it work?
> >
> > I have no idea, and I'd not even call that a workaround. It just
> > seems that if you change random things, it starts to work.
>
> I see. That obsoletes my next question in the queue addressing side effects.
>
> What would you propose to proceed?
1) Don't panic. ;)
2) Try the attached patch.
Now, if I'd understand what (a) the patch in
HandleMapRequestKeepRaised() is supposed to do, and (b) why
XUnmapWIndow() is called in HandleUnmapNotify(), I think I could
write a decent fix instead of jsut disabling the parts of the code
that cause trouble.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
>From c179137faffbdebc5e2875a0f418b4679dc4fe94 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sun, 20 Nov 2016 23:47:52 +0100
Subject: [PATCH] fix
---
fvwm/events.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/fvwm/events.c b/fvwm/events.c
index cc4cc8f..93cb251 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -518,6 +518,7 @@ static Bool test_map_request(
return rc;
}
+#if 0 /*!!!*/
/* Test for ICCCM2 withdraw requests by syntetic events on the root window */
static Bool test_withdraw_request(
Display *display, XEvent *event, XPointer arg)
@@ -544,6 +545,7 @@ static Bool test_withdraw_request(
return rc;
}
+#endif
static int _pred_weed_accumulate_expose(
Display *display, XEvent *ev, XPointer arg)
@@ -3339,6 +3341,7 @@ void HandleMapRequestKeepRaised(
/* If the window has never been mapped before ... */
if (!fw || (fw && DO_REUSE_DESTROYED(fw)))
{
+#if 0 /*!!!*/
check_if_event_args args;
XEvent dummy;
@@ -3392,6 +3395,7 @@ void HandleMapRequestKeepRaised(
return;
}
+#endif
/* Add decorations. */
fw = AddWindow(
@@ -4159,20 +4163,31 @@ void HandleUnmapNotify(const evh_args_t *ea)
XEvent dummy;
XEvent map_event;
const XEvent *te = ea->exc->x.etrigger;
- int weMustUnmap;
Bool focus_grabbed;
Bool must_return = False;
Bool do_map = False;
+ int do_unmap;
FvwmWindow * const fw = ea->exc->w.fw;
Window pw;
Window cw;
DBUG("HandleUnmapNotify", "Routine Entered");
- /* Don't ignore events as described below. */
- if (te->xunmap.event != te->xunmap.window &&
- (te->xunmap.event != Scr.Root || !te->xunmap.send_event))
+ if (te->xunmap.event == te->xunmap.window)
+ {
+ /* Handle normally. */
+ do_unmap = 1;
+ }
+ else if (te->xunmap.event == Scr.Root && te->xunmap.send_event)
+ {
+ /* Synthetic event on the root window; the client should have
+ * taken care of calling XUnmapWindow. */
+ do_unmap = 0;
+ }
+ else
{
+ /* Nothing to do except updating some states. */
+ do_unmap = 0;
must_return = True;
}
@@ -4183,10 +4198,12 @@ void HandleUnmapNotify(const evh_args_t *ea)
* unmapped (which is the case for fvwm for IconicState).
* Unfortunately, we looked for the FvwmContext using that field, so
* try the window field also. */
- weMustUnmap = 0;
- if (!fw)
+ if (fw)
+ {
+ do_unmap = 0;
+ }
+ else
{
- weMustUnmap = 1;
if (XFindContext(
dpy, te->xunmap.window, FvwmContext,
(caddr_t *)&fw) == XCNOENT)
@@ -4206,7 +4223,7 @@ void HandleUnmapNotify(const evh_args_t *ea)
return;
}
- if (weMustUnmap)
+ if (do_unmap)
{
Bool is_map_request_pending;
check_if_event_args args;
--
1.7.10.4
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> > What is the secret behind this move? How does it work? > > I have no idea, and I'd not even call that a workaround. It just > seems that if you change random things, it starts to work. I see. That obsoletes my next question in the queue addressing side effects. What would you propose to proceed? Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Sun, Nov 20, 2016 at 12:30:55PM +, Jürgen Hartmann wrote:
> > Try commenting out only the body of the if-condition, i.e.
> >
> > --
> > args.do_return_true_cr = False;
> > if (
> > FCheckIfEvent(
> > dpy, &dummy, test_withdraw_request,
> > (XPointer)&args))
> > {
> > #if 0 /*!!!*/
> > ...
> > #endif
> > }
> > --
>
> This does the magic!
>
> It seems to work perfectly, even if this is the only change done against the
> officially released sources.
>
> It works for both, Player 6.0.6 and Workstation 9.0.4.
>
> Thank you very much, Dominik, for your persistent and successful help!!!
>
> What is the secret behind this move? How does it work?
I have no idea, and I'd not even call that a workaround. It just
seems that if you change random things, it starts to work.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> Try commenting out only the body of the if-condition, i.e.
>
> --
> args.do_return_true_cr = False;
> if (
> FCheckIfEvent(
> dpy, &dummy, test_withdraw_request,
> (XPointer)&args))
> {
> #if 0 /*!!!*/
> ...
> #endif
> }
> --
This does the magic!
It seems to work perfectly, even if this is the only change done against the
officially released sources.
It works for both, Player 6.0.6 and Workstation 9.0.4.
Thank you very much, Dominik, for your persistent and successful help!!!
What is the secret behind this move? How does it work?
Juergen
(grinning happily)
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Sat, Nov 19, 2016 at 08:40:28PM +, Jürgen Hartmann wrote:
>
> > > Unfortunately, this seems not to have any influence to our issue. After
> > > installing the modified binaries, Vmware still shows the old behavior:
> > > Returning from fullscreen mode yields a vanished window. This applies
> > > to Player 6.0.6 and Workstation 9.0.4.
> > >
> > > Did I throw out the right piece of code?
> >
> > Are you sure the patched fvwm was running?
>
> That also was my first concern. But yes, I double checked that.
Try commenting out only the body of the if-condition, i.e.
--
args.do_return_true_cr = False;
if (
FCheckIfEvent(
dpy, &dummy, test_withdraw_request,
(XPointer)&args))
{
#if 0 /*!!!*/
...
#endif
}
--
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> > what resulted in the following three warnings during compilation:
>
> Yeah, forget about the warnings.
Sure.
> > Unfortunately, this seems not to have any influence to our issue. After
> > installing the modified binaries, Vmware still shows the old behavior:
> > Returning from fullscreen mode yields a vanished window. This applies
> > to Player 6.0.6 and Workstation 9.0.4.
> >
> > Did I throw out the right piece of code?
>
> Are you sure the patched fvwm was running?
That also was my first concern. But yes, I double checked that.
> Other than that I have
> also this block commented out from an earlier experiment:
>
> #if 0 /*!!!*/
> if (
> fw != NULL && IS_SCHEDULED_FOR_DESTROY(fw) &&
> e->type != DestroyNotify)
> {
> return;
> }
> #endif
I also took this one out, but see no change.
The same is true after additionally applying the patch
0001-try-no-grabs-in-function-execution.patch
that you supplied in an earlier posting.
I checked it for both, Player and Workstation, with equal result.
Maybe you can post a patch of your experimental version of sources against
the officially released ones in
https://github.com/fvwmorg/fvwm/releases/download/2.6.7/fvwm-2.6.7.tar.gz
so we have assuredly identical copies? What do you think?
Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Sat, Nov 19, 2016 at 03:58:26PM +, Jürgen Hartmann wrote:
> Thank you for your suggestion, Dominik:
>
> > For the time being you can circumvent the problem by removing the whole
> >
> > if (
> > FCheckIfEvent(
> > dpy, &dummy, test_withdraw_request,
> > (XPointer)&args)) {
> > ...
> > }
> >
> > from HandleMapRequestKeepRaised.
>
> I found this piece of code (part of HandleMapRequestKeepRaised) in the
> released Fvwm 2.6.7 sources in the file
>
>fvwm-2.6.7/fvwm/events.c
>
> spanning from line 3078 to 3123. I deactivated it by means of
>
>#if 0
>...
>#endif
>
> what resulted in the following three warnings during compilation:
Yeah, forget about the warnings.
> Unfortunately, this seems not to have any influence to our issue. After
> installing the modified binaries, Vmware still shows the old behavior:
> Returning from fullscreen mode yields a vanished window. This applies
> to Player 6.0.6 and Workstation 9.0.4.
>
> Did I throw out the right piece of code?
Are you sure the patched fvwm was running? Other than that I have
also this block commented out from an earlier experiment:
#if 0 /*!!!*/
if (
fw != NULL && IS_SCHEDULED_FOR_DESTROY(fw) &&
e->type != DestroyNotify)
{
return;
}
#endif
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you for your suggestion, Dominik:
> For the time being you can circumvent the problem by removing the whole
>
> if (
> FCheckIfEvent(
> dpy, &dummy, test_withdraw_request,
> (XPointer)&args)) {
> ...
> }
>
> from HandleMapRequestKeepRaised.
I found this piece of code (part of HandleMapRequestKeepRaised) in the
released Fvwm 2.6.7 sources in the file
fvwm-2.6.7/fvwm/events.c
spanning from line 3078 to 3123. I deactivated it by means of
#if 0
...
#endif
what resulted in the following three warnings during compilation:
---
CC events.o
events.c: In function ‘HandleMapRequestKeepRaised’:
events.c:3073:10: warning: unused variable ‘dummy’ [-Wunused-variable]
XEvent dummy;
^
events.c:3072:23: warning: variable ‘args’ set but not used
[-Wunused-but-set-variable]
check_if_event_args args;
^
events.c: At top level:
events.c:253:13: warning: ‘test_withdraw_request’ defined but not used
[-Wunused-function]
static Bool test_withdraw_request(
^
---
But make completed successfully
Unfortunately, this seems not to have any influence to our issue. After
installing the modified binaries, Vmware still shows the old behavior:
Returning from fullscreen mode yields a vanished window. This applies
to Player 6.0.6 and Workstation 9.0.4.
Did I throw out the right piece of code?
Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you, Dominik, for this result: > On Fri, Nov 18, 2016 at 10:33:20PM +, Jürgen Hartmann wrote: > > > A short update: Version 6.0.6 requires an old kernel, version > > > 12.5 is downloading now (which is a matter of several hours given > > > the local internet speed). > > > > Player 6 <-> Workstation 10 supp. kernel 3.1.0 to 3.11.6 > > Ah, good, with 3.10, it runs now. So, runnig a virtual machine > with no OS now, and it tries to get a config over DHCP. Great! That is good news. And this searching for DHCP is the expected behavior. Good. > 1. Move cursor to menu bar of the vm window. > 2. Press ctrl-alt-enter => goes to fullscreen mode. > 3. Press ctrl-alt-enter => window vanishes, the keyboard is still >grabbed, but the mouse os not. It's not possible to type >commands. That is exactly the issue I mean. The window vanishes, but should appear in normal window mode. This is what former versions of Vmware did in former versions of Fvwm, and what the current Vmware does in (more or less) contemporary Kwin and Icewm versions. Right now I see after step 3, that while the keyboard is grabbed by the invisible Vmware, Fvwm decorated window with the shell from where Vmware was started as the active window as it would have focus. I don't know whether this is important, it is just an observation. (I use Fvwm 2.6.7 in its default configuration, for the case that its focus policy matters.) > 4. Press ctrl-alt-enter => window comes back in window mode. The >keyboard is still grabbed, but the mouse is not, so it can be >used to interact with fvwm. There, we see a very strange behavior with (that version of ?) Vmware Player--it is completely new to me, since Workstation (9.0.4) does not show that: When the window reappears as a normal window in step 4, Vmware Player thinks he is still in fullscreen mode. This can be seen by its menu bar: It is the normally hidden bar that automatically rolls out when the mouse touches the upper rim of the window where the bar is located. In contrast to the (static) menu bar that is (typically) used in normal mode, it has a a "Pin" button at its left end and _, #, X buttons at its right. (There are further differences.) In case of Workstation, step 4 brings it back to plain fullscreen mode with additional ctrl-alt-enter toggling between vanished and fullscreen window. > 5. Move the pointer to the menu bar and press "X" => the keyboard >grab is released. In my case (trying to reproduce with Vmware Player 6.0.6), step 5 brings me a dialog window asking whether to suspend the running virtual machine. Answering "yes" saves the machines current state and exits the player. When the machine is "played" the next time, it starts right away in fullscreen mode, since Vmware thinks this was the mode it was in when we left last time, cf. my comments to step 4. Therefore, it requires some caution to establish a well defined state after each test run: The virtual machine should be switched off (not suspended) in a window that Vmware thinks to be in normal mode. It seems that this can be achieved from any state with a running virtual machine by the following procedure: 1: With Vmware having the focus (grabbed keyboard) hit ctrl-alt-enter often enough to have the Vmware window vanished. (Then Vmware thinks to be in normal mode.) 2: Send the vmplayer process a SIGTERM. If necessary, keyboard grab can released from Vmware by ctrl-alt. 3: Answer the popping up dialog that asks whether to suspend the running virtual machine with yes. Vmware will save the current state of that machine (showing a progress indicator) and exit. 4: Start vmplayer again and play the suspended virtual machine. 5: Use Vmware's menu bar to select "Virtual Machine"/Power/"Power Off Guest" confirming the popping up dialogs. (If necessary, keyboard grab can released from Vmware by ctrl-alt.) This will exit the Player leaving things in a well-defined state. > Is 3 what you mean? Yes it is. See above. > Is there a way to have this window vanish but > not hold the keyboard grab? Yes. Vmware generally uses ctrl-alt (without enter) as the hotkey to release the grab. It works here. > Ciao > > Dominik ^_^ ^_^ Thank you very much for your effort so far. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
It turns out that the below patch from 2007 has broken it. Now if
anybody knows where the mailing list archive has gone and how to
find the thread related to this patch ...
For the time being you can circumvent the problem by removing the whole
if (
FCheckIfEvent(
dpy, &dummy, test_withdraw_request,
(XPointer)&args)) {
...
}
from HandleMapRequestKeepRaised.
--
commit 31fcfe2130b9c3d10fd7618d4c65290b42f64f11
Author: griph
AuthorDate: Mon Dec 3 20:22:23 2007 +
Commit: griph
CommitDate: Mon Dec 3 20:22:23 2007 +
* don't map new windows that have a pending ICCCM2 request to go into
WithdrawnState (synthetic UnmapNotify)
---
fvwm/events.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/fvwm/events.c b/fvwm/events.c
index 65e194f..e51421e 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -228,6 +228,33 @@ static Bool test_map_request(
return rc;
}
+/* Test for ICCCM2 withdraw requests by syntetic events on the root window */
+static Bool test_withdraw_request(
+ Display *display, XEvent *event, XPointer arg)
+{
+ check_if_event_args *cie_args;
+ Bool rc;
+
+ cie_args = (check_if_event_args *)arg;
+ cie_args->ret_does_match = False;
+ if (event->type == UnmapNotify &&
+ event->xunmap.window == cie_args->w &&
+ event->xany.send_event == True &&
+event->xunmap.event == FW_W(&Scr.FvwmRoot))
+ {
+ cie_args->ret_type = UnmapNotify;
+ cie_args->ret_does_match = True;
+ rc = cie_args->do_return_true;
+ }
+ else
+ {
+ cie_args->ret_type = 0;
+ rc = False;
+ }
+
+ return rc;
+}
+
Bool test_button_event(
Display *display, XEvent *event, XPointer arg)
{
@@ -2897,6 +2924,22 @@ void HandleMapRequestKeepRaised(
/* If the window has never been mapped before ... */
if (!fw || (fw && DO_REUSE_DESTROYED(fw)))
{
+ Bool is_unmap_request_pending;
+ check_if_event_args args;
+ XEvent dummy;
+
+ args.w = ew;
+ args.do_return_true = True;
+ args.do_return_true_cr = False;
+ if (
+ FCheckIfEvent(
+ dpy, &dummy, test_withdraw_request,
+ (XPointer)&args)) {
+ /* The window is moved back to the WitdrawnState
+* immideately. Don't map it. */
+ return;
+ }
+
/* Add decorations. */
fw = AddWindow(ea->exc, ReuseWin, win_opts);
if (fw == AW_NO_WINDOW)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Fri, Nov 18, 2016 at 10:33:20PM +, Jürgen Hartmann wrote: > > A short update: Version 6.0.6 requires an old kernel, version > > 12.5 is downloading now (which is a matter of several hours given > > the local internet speed). > > Player 6 <-> Workstation 10 supp. kernel 3.1.0 to 3.11.6 Ah, good, with 3.10, it runs now. So, runnig a virtual machine with no OS now, and it tries to get a config over DHCP. 1. Move cursor to menu bar of the vm window. 2. Press ctrl-alt-enter => goes to fullscreen mode. 3. Press ctrl-alt-enter => window vanishes, the keyboard is still grabbed, but the mouse os not. It's not possible to type commands. 4. Press ctrl-alt-enter => window comes back in window mode. The keyboard is still grabbed, but the mouse is not, so it can be used to interact with fvwm. 5. Move the pointer to the menu bar and press "X" => the keyboard grab is released. Is 3 what you mean? Is there a way to have this window vanish but not hold the keyboard grab? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> A short update: Version 6.0.6 requires an old kernel, version > 12.5 is downloading now (which is a matter of several hours given > the local internet speed). Sorry, I should have mentioned that this might be an issue. Each version of Vmware Workstation or Player supports only very few versions of the Linux kernel. (This has the very annoying consequence that one has to purchase a new license every few kernel updates.) For a rough orientation, Vmware offers the following compatibility map on their web page: http://kb.vmware.com/kb/2088579 It maps supported Linux distributions for each version of Vmware Workstation. (Unfortunately they don't list kernel versions, only versions of distributions.) To use that list for Vmware Player, one has to know that its version numbers differ from those of the corresponding Workstation counterpart. While I didn't find it documented in a closed form anywhere, I guessed the following correspondences from gossips in the web (they might be false): Player 4 <-> Workstation 8 supp. kernel 2.6.18 to 2.6.37 Player 5 <-> Workstation 9 supp. kernel 2.6.37 Player 6 <-> Workstation 10 supp. kernel 3.1.0 to 3.11.6 Player 7 <-> Workstation 11 supp. kernel 3.7.10 to 3.18 Player 12 <-> Workstation 12 supp. kernel 3.7.10 to 4.7 In addition, the compatibility to a given kernel strongly depends on the sub-version of the Vmware product. > I'll have to find some 64-bit box to run it. If I can assist you in some way, please let me know. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
A short update: Version 6.0.6 requires an old kernel, version 12.5 is downloading now (which is a matter of several hours given the local internet speed). I'll have to find some 64-bit box to run it. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
In my last post, I described the creation of a virtual machine, saying that most of the offered setting can be left on their defaults. But when it is about to choose the guest operating system, it is better to select "Windows 3.1" than the default "Windows 7": I encountered some driver problems when booting the latter. Sorry. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you, Chris Siebenmann, for your explanation: > I believe that VMWare grabs the X pointer when it converts the X > pointer into a virtual machine mouse (or non-mouse, if the virtual > machine isn't using it). The pointer stays grabbed until you manually > tell VMWare to release it or, under some conditions, until you move the > mouse pointer 'outside' the virtual machine's window. I think VMWare > also grabs the keyboard here for the same reason. > > (I believe that the VM needs to be using the mouse and have the VMWare > tools installed, at which point the in-VM driver signals VMWare itself > to let go of the mouse.) > That's right: The Vmware jargon explicitly uses the term "grab" for this. Mouse and keyboard are "grabbed" by the virtual machine when the latter's display gets clicked. The grab is released again when a specific hotkey is pressed (Ctrl-Alt) or, if the Vmware Tools are installed in the guest system (and the mouse is supported), when the mouse hits the border of the virtual machine's display. > All of this is kind of a hack. VMWare wants 100% of the mouse and > keyboard events to go to the virtual machine without your host > environment getting in the way, even if what you're doing normally > has special meaning to the host. > > - cks It could be, that Vmware tries in this way to make the host system as transparent as possible and to improve the user's illusion to interact with a real machine instead of a virtual one. But the resulting all-hardware-is-mine attitude seems to be the same in fullscreen and in normal mode. Juergen
FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Using Fvwm for decades now, I am unfortunately not very familiar with its
details nor with the tools or concepts of Xorg. So I hope that somebody on
this mailing list can advice me a solution or a workaround for the following
issue:
On my Linux host system (Xorg 7.6 / Kernel 3.11.6) I use Fvwm 2.6.7 as window
manager (congratulation to the new default configuration which I like very
much) and Vmware Workstation 9.0.4 to run virtual machines that use variants
of MS Windows as guest operating systems.
Now, when I switch a virtual machine that is displayed in fullscreen mode
back to normal window mode, I get the normal Fvwm desktop but no Vmware
window: The expected Vmware GUI window is neither visible, nor iconified
somewhere, nor brought back by
All MoveToScreen
(issued in FvwmConsole), nor gets listed by FvwmWinList.
However, according to
xprop -name vmware
the window still exists with the following properties
(newlines and indents inserted for readability):
WM_CLASS(STRING) = "vmware", "Vmware"
WM_COMMAND(STRING) = { "vmware" }
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x102
WM_CLIENT_LEADER(WINDOW): window id # 0x101
_NET_WM_PID(CARDINAL) = 7626
WM_LOCALE_NAME(STRING) = "de_DE.UTF-8"
WM_CLIENT_MACHINE(STRING) = "unikat"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified size: 10 by 10
WM_PROTOCOLS(ATOM):
protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
WM_ICON_NAME(STRING) = "vmware"
_NET_WM_ICON_NAME(UTF8_STRING) = "vmware"
WM_NAME(STRING) = "vmware"
_NET_WM_NAME(UTF8_STRING) = "vmware"
Actually, these properties didn't change since Vmware Workstation was freshly
started in window mode.
In addition, `ps' says that all necessary vmware processes are still running,
and it is possible to reopen that window--with a still running virtual
machine--using a second instance of Vmware Workstation.
This issue is not specific to Fvwm's version 2.6.7 as I found the same
behavior using its predecessors 2.6.6 and 2.6.5.
On the other hand, this problem does not not show up if Kwin 4.11.2 or
Icewm 1.2.38 is used as window manager: With one of these, the normal Vmware
GUI window shows up right after switching off Vmware's fullscreen mode.
To understand what is going on, I looked to the output that these window
managers produce when the fullscreen mode is switched on and off:
Kwin says nothing related.
Fvwm 2.6.7 outputs the following lines when the fullscreen mode is turned
on (!) at the first place (newlines and indents inserted for readability):
[fvwm][ComplexFunction]:
<> Grab failed in function EWMHActivateWindowFunc, unable to
execute immediate action
[fvwm][GetWindowSizeHints]:
<> reason: 1: The hints have been ignored because the window's
current size would have become invalid. The new hints will become active
when the window generates the next ConfigureRequest.
[fvwm][GetWindowSizeHints]:
<> reason: 1: The hints have been ignored because the window's
current size would have become invalid. The new hints will become active
when the window generates the next ConfigureRequest.
[fvwm][GetWindowSizeHints]:
<> reason: 1: The hints have been ignored because the window's
current size would have become invalid. The new hints will become active
when the window generates the next ConfigureRequest.
[fvwm][GetWindowSizeHints]:
<> reason: 1: The hints have been ignored because the window's
current size would have become invalid. The new hints will become active
when the window generates the next ConfigureRequest.
Icewm 1.2.38 comments the switching off (!) of the fullscreen mode like that
(newlines and indents inserted for readability):
IceWM: MappingNotify
IceWM: APP BUG?
configureRequest for window 40011C sent to destroyed frame 83!
IceWM: APP BUG?
configureRequest for window 40011C sent to destroyed frame 83!
IceWM: APP BUG?
mapRequest for window 40011C sent to destroyed frame 83!
IceWM: APP BUG?
configureRequest for window 40011C sent to destroyed frame 83!
I don't have the knowledge to interpret these messages in detail. But if you
force me to guess, I would say that there is a bug in Vmware Workstation that
happens to be treated in a more tolerant way by Kwin and Icewm than it is by
Fvwm.
Unfortunately, I am bound to use that version of Vmware since it was a hard
battle to find a working combination of guest system, virtual machine,
virtualization software and Linux kernel version. In particular, this rules
out the contemporary versions of Vmware Player and Oracle's Virtual Box.
Looking at Vmware's web pages, I found the contribution
https://communities.vmware.com/message/2207791#2207791
of 2013-03-08 where the user "dl8dtl" asks for help on the exactly same
problem that he encountered with Vmware Player. Unfortunately he was never
answered.
And since Vmware is closed source software (at least p
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you very much, Dominik, for your reply and the enlightening explanations. > On the site you mentioned below there are only 64-bit Linux > binaries available for download, and only for version 12. I'd > like to help, but I need a 32 bit Linux version that shows the bug > and that can actually be downloaded (i.e. I can't download > anything from the site because the download links trigger a > redirect loop). As far as I understood, the latest version of Vmware Player that supports 32 bit architectures on Linux hosts is 6.0.6. But we are lucky: It shows the same issue (at least its 64 bit version does, as that is the only one I can test). The package can be downloaded by wget -c https://download3.vmware.com/software/player/file/ VMware-Player-6.0.6-2700073.i386.bundle (without linebreak). The installation is done by executing the downloaded file as root (after setting the executable bit). Either during installation or during the first start you will be prompted to enter an e-mail address that will be used for (automatic) registration at Vmware. Be prepared to get "valuable product information" to this address. Once installed, the player is started by vmplayer The easiest way for a test is to create an empty virtual machine by clicking the field "Create a New Virtual Machine" in the player's main window. Choose "I will install the operating system later." (which will never happen) in the following dialog. The settings in the next 4 pages of that dialog don't matter and can be left unchanged. Back in the main window of the player, you can start the new virtual machine by pressing "Play virtual machine" and confirming the hints that will pop up. The machine will boot, see no system and halt. With a click into to area of the virtual machine's display (in the player window), the mouse and the keyboard focus will be "grabbed" by the virtual machine. I am not sure whether this term "grab" from the Vmware jargon is identical to that of the X terminology, but it seems reasonable. During the grab, mouse and keyboard events (aside from some Vmware hotkeys) will be consumed and processed by the virtual machine. If there would be a guest system with mouse support running in the virtual machine, that system's mouse pointer would "execute" the mouse movements, but staying confined in the virtual machines screen area. The grab can be released by pressing the hotkey Ctrl-Alt. With grabbed mouse and focus, the fullscreen mode can be toggled by the hotkey Ctrl-Alt-Enter. Otherwise it can be entered via the "Virtual Machine" menu in the player's main window. In fullscreen mode, there is a menu bar hidden behind the upper rim of the screen in the center that will roll out when touched with the mouse which has to be ungrabbed for this. With the second button from the right in that menu bar the fullscreen mode can also be left. Due to the problem that this is all about, the only option to access the player after leaving fullscreen mode is to kill it. When using SIGTERM for that, the player asks whether to suspend the still running virtual machine, so that its execution can be resumed on its next virtual power cycle. >> Fvwm 2.6.7 outputs the following lines when the fullscreen mode is turned >> on (!) at the first place (newlines and indents inserted for readability): >> >>[fvwm][ComplexFunction]: >><> Grab failed in function EWMHActivateWindowFunc, unable to >>execute immediate action > > Some program, probably vmware, has asked fvwm to "activate" some > window. Activation is a term from the EWMH specification and > usually asks the window manager to make the window visible (switch > to its page, bring it to the front, give it focus). In fvwm the > function to execute on the window can be changed by the user. > > During immediate function execution fvwm tries to get exclusive > control of the pointer (a "grab"). This failed in the given case > because some other program held the grab. Fvwm retries grabbing > for a second before giving up (the function is aborted). It seems > that for whatever reason vmware grabbed control over the pointer > for a long time, which it really should not do because it blocks > all other applications, including the window manager. But this is > not related to the vanishing window. I see. So it is pretty much possible that we have a fight between Vmware's grab for the virtual machine that I described above and Fvwm trying to get the grab for the execution of the immediate function. > [Very interesting explanations skipped.] > It seems to be unmapped and can thus not be controlled in any way > by the window manager. To double check that you can issue > > all echo $w $[w.name] > > from FvwmConsole and check if the window is mentioned in the > console output. This gave the following output - so sign of Vmware: [fvwm][expand_vars]: <> Use $[w.id] instead of $w [fvwm][Echo]: 0x1600022 'FvwmConsole' [fvwm][expand_vars]: <> Use $[w.id] inst
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
>> All of this is kind of a hack. VMWare wants 100% of the mouse and >> keyboard events to go to the virtual machine without your host >> environment getting in the way, even if what you're doing normally >> has special meaning to the host. > > I see. However, if it does that, it cannot expect to be able to > communicate with the outside world, as it seems to do. Maybe this *is* the > Problem after all. > > @Jürgen: Could you try whether the attached patch helps? (It > disables all grabs during function execution and *does* break > complex functions with non-immediate actions.) I tried the patch. Unfortunately, it makes no difference to our problem. After all, the error message from Fvwm about the failed grab [fvwm][ComplexFunction]: <> Grab failed in function EWMHActivateWindowFunc, unable to execute immediate action occurs when Vmware is switched _to_ fullscreen mode. And at this stage no window is lost yet. This happens only when switching back from fullstreen to normal mode. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Previously, I mailed the output of xev for the Vmware's client and frame
windows while switching off fullscreen mode, as advised by Dominik Vogt.
Since therein there were UnmapNotify and MapNotify events on the client side
and a DestroyNotify event for the frame window, I thought that it might be
useful to have both outputs merged with the events entries being in the right
temporal order.
So I repeated the test using
sleep 10;
{ xev -id 0x83 & xev -id 0x401e6a & } > xev.client-n-frame;
sleep 30; killall xev
(without linebreaks).
Pleas note that the ID of the frame window has changed compared to my earlier
mail. This time an xwininfo -tree yielded:
---
xwininfo: Window id: 0x83 "WinVM - VMware Workstation"
Root window id: 0x8e (the root window) (has no name)
Parent window id: 0x401e6a (has no name)
2 children:
0x801019 (has no name): () 1920x1080+0+0 +0+0
2 children:
0x801ba7 (has no name): () 1512x4+176+-64 +176+-64
0x801018 (has no name): () 1920x1080+0+0 +0+0
3 children:
0x801017 (has no name): () 16x16+1227+818 +1227+818
0x800dea (has no name): () 1920x1080+0+0 +0+0
2 children:
0x800de9 "MKSSV-MKSWindowID#0": () 1440x1080+240+0 +240+0
1 child:
0x181 "MKSWindow#0": () 1440x1080+0+0 +240+0
0x800ded (has no name): () 1440x1080+240+0 +240+0
0x8010c0 "MKSSV-MKSWindowID#1": () 1225x919+305+65 +305+65
1 child:
0x189 "MKSWindow#1": () 1225x919+0+0 +305+65
0x84 (has no name): () 1x1+-1+-1 +-1+-1
---
while plain xwininfo said:
---
xwininfo: Window id: 0x83 "WinVM - VMware Workstation"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 1920
Height: 1080
Depth: 24
Visual: 0x20
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x22 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+0 -0+0 -0-0 +0-0
-geometry 1920x1080+0+0
---
So this time we have
client ID: 0x83
frame ID:0x401e6a
After
sleep 10;
{ xev -id 0x83 & xev -id 0x401e6a & } > xev.client-n-frame;
sleep 30; killall xev
the contents of xev.client-n-frame was (with surprisingly little collisions):
---
UnmapNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x83, from_configure NO
FocusIn event, serial 18, synthetic NO, window 0x401e6a,
mode NotifyWhileGrabbed, detail NotifyI
UnmapNotify event, serial 18, synthetic NO, window 0x83,
event 0x83, window 0x83, from_configure NO
FocusOut event, serial 18, synthetic NO, window 0x83,
mode NotifyWhileGrabbed, detail NotifyAncestor
KeymapNotify event, serial 18, synthetic NO, window 0x0,
keys: 0 0 0 0 48 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Expose event, serial 18, synthetic NO, window 0x401e6a,
(0,0), width 1920, height 1080, count 0
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x28 (WM_NORMAL_HINTS), time 89766065, state PropertyNewValue
MapNotify event, serial 18, synthetic NO, window 0x83,
event 0x83, window 0x801019, override NO
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x23 (WM_HINTS), time 89766065, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x152 (_NET_WM_STATE), time 89766065, state PropertyDelete
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x150 (_NET_WM_DESKTOP), time 89766065, state PropertyDelete
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x28 (WM_NORMAL_HINTS), time 89766065, state PropertyNewValue
VisibilityNotify event, serial 18, synthetic NO, window 0x401e6a,
state VisibilityPartiallyObscured
ConfigureNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x401e6a, (5,23), width 1920, height 1080,
border_width 0, above 0x4030fb, override NO
Expose event, serial 18, synthetic NO, window 0x401e6a,
(0,0), width 1910, height 23, count 1
Expose event, serial 18, synthetic NO, window 0x401e6a,
(0,23), width 5, height 1029, count 0
Expose event, serial 18, synthetic NO, window 0x401e6a,
(1910,0),
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you, Dominik, for your answer: > On Thu, Nov 17, 2016 at 08:53:21PM +, Jürgen Hartmann wrote: >> Previously, I mailed the output of xev for the Vmware's client and frame >> windows while switching off fullscreen mode, as advised by Dominik Vogt. > > Please just call me Dominik. All right, I will do. >> Since therein there were UnmapNotify and MapNotify events on the client side >> and a DestroyNotify event for the frame window, I thought that it might be >> useful to have both outputs merged with the events entries being in the right >> temporal order. > > Thanks, Jürgen; I've downloaded the binary but hadn't had a chance > to try it yet. I just need some more time to do that, in the mean > time you don't need to provide more data. If the binary "works" > as expected, I'll have all the data needed. I see. Thank you for the clarification. So I will patiently await the things coming. I am really glad that you are willing to help here. Thank you very much. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Thu, Nov 17, 2016 at 08:53:21PM +, Jürgen Hartmann wrote: > Previously, I mailed the output of xev for the Vmware's client and frame > windows while switching off fullscreen mode, as advised by Dominik Vogt. Please just call me Dominik. > Since therein there were UnmapNotify and MapNotify events on the client side > and a DestroyNotify event for the frame window, I thought that it might be > useful to have both outputs merged with the events entries being in the right > temporal order. Thanks, Jürgen; I've downloaded the binary but hadn't had a chance to try it yet. I just need some more time to do that, in the mean time you don't need to provide more data. If the binary "works" as expected, I'll have all the data needed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Tue, Nov 15, 2016 at 05:23:09PM -0500, Chris Siebenmann wrote:
> > During immediate function execution fvwm tries to get exclusive
> > control of the pointer (a "grab"). This failed in the given case
> > because some other program held the grab. Fvwm retries grabbing
> > for a second before giving up (the function is aborted). It seems
> > that for whatever reason vmware grabbed control over the pointer
> > for a long time, which it really should not do because it blocks
> > all other applications, including the window manager. But this is
> > not related to the vanishing window.
>
> I believe that VMWare grabs the X pointer when it converts the X
> pointer into a virtual machine mouse (or non-mouse, if the virtual
> machine isn't using it). The pointer stays grabbed until you manually
> tell VMWare to release it or, under some conditions, until you move the
> mouse pointer 'outside' the virtual machine's window. I think VMWare
> also grabs the keyboard here for the same reason.
>
> (I believe that the VM needs to be using the mouse and have the VMWare
> tools installed, at which point the in-VM driver signals VMWare itself
> to let go of the mouse.)
>
> All of this is kind of a hack. VMWare wants 100% of the mouse and
> keyboard events to go to the virtual machine without your host
> environment getting in the way, even if what you're doing normally
> has special meaning to the host.
I see. However, if it does that, it cannot expect to be able to
communicate with the outside world, as it seems to do. Maybe this *is* the
Problem after all.
@Jürgen: Could you try whether the attached patch helps? (It
disables all grabs during function execution and *does* break
complex functions with non-immediate actions.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
>From d000725dce2e0fc1b155c9adda14cf0d28899f72 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Wed, 16 Nov 2016 01:14:31 +0100
Subject: [PATCH] !try no grabs in function execution
---
fvwm/functions.c |8
1 file changed, 8 insertions(+)
diff --git a/fvwm/functions.c b/fvwm/functions.c
index 298cdd3..4cbe25f 100644
--- a/fvwm/functions.c
+++ b/fvwm/functions.c
@@ -1018,6 +1018,7 @@ static void execute_complex_function(
mask |= ECC_W;
}
+#if 0 /*!!!*/
/* we have to grab buttons before executing immediate actions because
* these actions can move the window away from the pointer so that a
* button release would go to the application below. */
@@ -1031,6 +1032,7 @@ static void execute_complex_function(
__cf_cleanup(&depth, arguments, cond_rc);
return;
}
+#endif
exc2 = exc_clone_context(exc, &ecc, mask);
__run_complex_function_items(
cond_rc, CF_IMMEDIATE, func, exc2, arguments,
@@ -1064,7 +1066,9 @@ static void execute_complex_function(
{
func->use_depth--;
__cf_cleanup(&depth, arguments, cond_rc);
+#if 0 /*!!!*/
UngrabEm(GRAB_NORMAL);
+#endif
return;
}
@@ -1078,7 +1082,9 @@ static void execute_complex_function(
{
func->use_depth--;
__cf_cleanup(&depth, arguments, cond_rc);
+#if 0 /*!!!*/
UngrabEm(GRAB_NORMAL);
+#endif
return;
}
}
@@ -1182,7 +1188,9 @@ static void execute_complex_function(
*/
func->use_depth--;
__cf_cleanup(&depth, arguments, cond_rc);
+#if 0 /*!!!*/
UngrabEm(GRAB_NORMAL);
+#endif
return;
}
--
1.7.10.4
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> During immediate function execution fvwm tries to get exclusive > control of the pointer (a "grab"). This failed in the given case > because some other program held the grab. Fvwm retries grabbing > for a second before giving up (the function is aborted). It seems > that for whatever reason vmware grabbed control over the pointer > for a long time, which it really should not do because it blocks > all other applications, including the window manager. But this is > not related to the vanishing window. I believe that VMWare grabs the X pointer when it converts the X pointer into a virtual machine mouse (or non-mouse, if the virtual machine isn't using it). The pointer stays grabbed until you manually tell VMWare to release it or, under some conditions, until you move the mouse pointer 'outside' the virtual machine's window. I think VMWare also grabs the keyboard here for the same reason. (I believe that the VM needs to be using the mouse and have the VMWare tools installed, at which point the in-VM driver signals VMWare itself to let go of the mouse.) All of this is kind of a hack. VMWare wants 100% of the mouse and keyboard events to go to the virtual machine without your host environment getting in the way, even if what you're doing normally has special meaning to the host. - cks
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Tue, Nov 15, 2016 at 01:08:08PM +, Jürgen Hartmann wrote: > On my Linux host system (Xorg 7.6 / Kernel 3.11.6) I use Fvwm 2.6.7 as window > manager (congratulation to the new default configuration which I like very > much) and Vmware Workstation 9.0.4 to run virtual machines that use variants > of MS Windows as guest operating systems. On the site you mentioned below there are only 64-bit Linux binaries available for download, and only for version 12. I'd like to help, but I need a 32 bit Linux version that shows the bug and that can actually be downloaded (i.e. I can't download anything from the site because the download links trigger a redirect loop). > Now, when I switch a virtual machine that is displayed in fullscreen mode > back to normal window mode, I get the normal Fvwm desktop but no Vmware > window: The expected Vmware GUI window is neither visible, nor iconified > somewhere, nor brought back by > >All MoveToScreen > > (issued in FvwmConsole), nor gets listed by FvwmWinList. That means that the window is not mapped. WIndow managers do not know anything about unmapped windows and can do nothing with them. > However, according to > >xprop -name vmware > > the window still exists with the following properties > (newlines and indents inserted for readability): > >WM_CLASS(STRING) = "vmware", "Vmware" ... That just means that a window with the name still exists. > Fvwm 2.6.7 outputs the following lines when the fullscreen mode is turned > on (!) at the first place (newlines and indents inserted for readability): > >[fvwm][ComplexFunction]: ><> Grab failed in function EWMHActivateWindowFunc, unable to >execute immediate action Some program, probably vmware, has asked fvwm to "activate" some window. Activation is a term from the EWMH specification and usually asks the window manager to make the window visible (switch to its page, bring it to the front, give it focus). In fvwm the function to execute on the window can be changed by the user. During immediate function execution fvwm tries to get exclusive control of the pointer (a "grab"). This failed in the given case because some other program held the grab. Fvwm retries grabbing for a second before giving up (the function is aborted). It seems that for whatever reason vmware grabbed control over the pointer for a long time, which it really should not do because it blocks all other applications, including the window manager. But this is not related to the vanishing window. >[fvwm][GetWindowSizeHints]: ><> reason: 1: The hints have been ignored because the window's >current size would have become invalid. The new hints will become active >when the window generates the next ConfigureRequest. Not interesting here. > Icewm 1.2.38 comments the switching off (!) of the fullscreen mode like that > (newlines and indents inserted for readability): > >IceWM: MappingNotify >IceWM: APP BUG? > configureRequest for window 40011C sent to destroyed frame 83! I'm unsure what this means exactly. It seems that icewm and vmware disagree about the state of the client window. vmware sent a ConfigureRequest event (moved or resized the window), and the window was mapped at that time because otherwise icewm would not have received the request. On the other hand the frame window (the one with the decorations and the client window inside) did not exist at that time, i.e. icewm had destroyed it. THat usually happens when a window was unmapped. So, when the request arrived, icewm thought the window was unmapped while it was actually mapped. Although vmware might have done something funny, this looks like an icewm bug (maybe they process events out of order). > To summarize, here are the questions I have right now: > >* What is this fullscreen mode in the first place? Is it a window at all > what we see? Is it managed by Fvwm? Fullscreen mode is a term of the EWMH spec. There's a special protocol to switch between fullscreen and normal modes. In fullscreen mode the window ist displayed at maximum size without decorations. The application can ask the window manager to switch between modes, and the window manager may or may not do so. >* What is that state that the hidden Vmware GUI window is in after > returning from fullscreen mode? > (Known to xprop, but unknown to FvwmWinList.) It seems to be unmapped and can thus not be controlled in any way by the window manager. To double check that you can issue all echo $w $[w.name] from FvwmConsole and check if the window is mentioned in the console output. Also try all iconify off all windowshade off all (vmware) resizemove 500p 500p 0p 0p >* Is there any tool to manipulate X windows at runtime, e.g. to move or > raise them or to change their geometry (aside from the window's border > and the handles there--it should be applicable to a hidden window)? That tool is fvwm. You can type
