Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

[Jürgen Hartmann]

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

[Dominik Vogt]

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

[Dominik Vogt]

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

[Jürgen Hartmann]

> > 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

[Dominik Vogt]

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 *)) == 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

[Jürgen Hartmann]

> > 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

[Dominik Vogt]

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, , test_withdraw_request,
> > (XPointer)))
> > {
> > #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

[Jürgen Hartmann]

> Try commenting out only the body of the if-condition, i.e.
>
> --
> args.do_return_true_cr = False;
> if (
> FCheckIfEvent(
> dpy, , test_withdraw_request,
> (XPointer)))
> {
> #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

[Dominik Vogt]

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, , test_withdraw_request,
(XPointer)))
{
#if 0 /*!!!*/
...
#endif
}
--
 
Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

[Dominik Vogt]

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, , test_withdraw_request,
> > (XPointer))) {
> > ...
> > }
> >
> > 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

[Dominik Vogt]

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, , test_withdraw_request,
(XPointer))) {
...
}

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())
+   {
+   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, , test_withdraw_request,
+   (XPointer))) {
+   /* 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

[Jürgen Hartmann]

> 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

[Jürgen Hartmann]

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

[Jürgen Hartmann]

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] 

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

[Jürgen Hartmann]

>>  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

[Jürgen Hartmann]

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,

Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode

[Jürgen Hartmann]

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

[Dominik Vogt]

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

[Dominik Vogt]

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(, arguments, cond_rc);
 		return;
 	}
+#endif
 	exc2 = exc_clone_context(exc, , 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(, arguments, cond_rc);
+#if 0 /*!!!*/
 		UngrabEm(GRAB_NORMAL);
+#endif
 		return;
 	}
 
@@ -1078,7 +1082,9 @@ static void execute_complex_function(
 		{
 			func->use_depth--;
 			__cf_cleanup(, arguments, cond_rc);
+#if 0 /*!!!*/
 			UngrabEm(GRAB_NORMAL);
+#endif
 			return;
 		}
 	}
@@ -1182,7 +1188,9 @@ static void execute_complex_function(
 	 */
 	func->use_depth--;
 	__cf_cleanup(, 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

[Chris Siebenmann]

> 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

[Dominik Vogt]

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