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

[Jürgen Hartmann]

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 # 0x1000002
WM_CLIENT_LEADER(WINDOW): window id # 0x1000001
_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]:
<<ERROR>> Grab failed in function EWMHActivateWindowFunc, unable to
execute immediate action

[fvwm][GetWindowSizeHints]:
<<WARNING>> 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]:
<<WARNING>> 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]:
<<WARNING>> 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]:
<<WARNING>> 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 800003!
IceWM: APP BUG?
configureRequest for window 40011C sent to destroyed frame 800003!
IceWM: APP BUG?
mapRequest for window 40011C sent to destroyed frame 800003!
IceWM: APP BUG?
configureRequest for window 40011C sent to destroyed frame 800003!

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 partially), Fvwm seems
to be the the only possible place to achieve something.

Searching the Fvwm mailing lists, the thread

http://www.mail-archive.com/***@fvwm.org/msg01287.html

started by Harald Dunkel on 2010-04-29 seems loosely related, but does not
help in this situation.

Following Thomas Adam's advice in

http://fvwmforums.org/phpBB3/
viewtopic.php?f=33&t=2000&p=11330&hilit=vmware

--which of course addresses a totally different problem, but that is related
to Vmware--I attributed the styles

EWMHIgnoreStateHints
EWMHIgnoreWindowType

to "Vmware*", achieving some effect to some of the transient windows that pop
up during the startup of the virtual machine but not to the actual problem.

If somebody likes to reproduce this problem, it can be done using for example
the Vmware Player 12.5.1 (current version) which is freely available from

http://www.vmware.com/products/player/playerpro-evaluation.html

Therein, it suffices to create a new virtual machine with an empty disk (no
system), power it on, an switching to fullscreen mode and back again. In
contrast to Workstation, a second instance of Vmware Player is not able to
bring back the hidden window.

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? Or by the X server? Or is it
realized by Vmware directly accessing the hardware?

* What is that state that the hidden Vmware GUI window is in after
returning from fullscreen mode?
(Known to xprop, but unknown to FvwmWinList.)

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

* Is it possible to tune Fvwm's configuration in some way, to achieve that
Vmware returns with a normal (visible) window from fullscreen mode?

* If not, is it possible to tune Fvwm's sources in some way to achieve
this? Perhaps by replicate the behavior of Kwin or Icewm in this
respect?
Pretty naive? I had a feeling.

* Do you see any solutions, workarounds, or starting points to proceed
with this problem?

In any case, thank you for still reading.
I would greatly appreciate any help.

Juergen

[Dominik Vogt]

This post might be inappropriate. Click to display it.

[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]:
>> <<ERROR>> 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]: <<DEPRECATED>> Use $[w.id] instead of $w
[fvwm][Echo]: 0x1600022 'FvwmConsole'
[fvwm][expand_vars]: <<DEPRECATED>> Use $[w.id] instead of $w
[fvwm][Echo]: 0x600022 '***@unikat:~'
[fvwm][expand_vars]: <<DEPRECATED>> Use $[w.id] instead of $w
[fvwm][Echo]: 0xa00001 'RightPanel'

> Also try
>
> all iconify off
> all windowshade off
> all (vmware) resizemove 500p 500p 0p 0p

Unfortunately, no Vmware window showed up.

> 1. Make the vmware window fullscreen and start a shell on top of it.
> 2. Run "xwininfo -tree", click on the fullscreen window. Save the
> output. Repeat with a plain "xwininfo".

Here is the output of "xwininfo -tree":
---------------------------------------------------------------------------
xwininfo: Window id: 0x800003 "WinVM - VMware Workstation"

Root window id: 0x8e (the root window) (has no name)
Parent window id: 0x40145d (has no name)
2 children:
0x80067b (has no name): () 1920x1080+0+0 +0+0
2 children:
0x800c56 (has no name): () 1512x4+176+-64 +176+-64
0x80067a (has no name): () 1920x1080+0+0 +0+0
3 children:
0x800679 (has no name): () 16x16+1227+818 +1227+818
0x80049d (has no name): () 1920x1080+0+0 +0+0
2 children:
0x80049c "MKSSV-MKSWindowID#0": () 1440x1080+240+0 +240+0
1 child:
0x1400001 "MKSWindow#0": () 1440x1080+0+0 +240+0
0x8004a0 (has no name): () 1440x1080+240+0 +240+0
0x800722 "MKSSV-MKSWindowID#1": () 1225x919+305+65 +305+65
1 child:
0x1400009 "MKSWindow#1": () 1225x919+0+0 +305+65
0x800004 (has no name): () 1x1+-1+-1 +-1+-1
---------------------------------------------------------------------------

And here the one of "xwininfo":
---------------------------------------------------------------------------
xwininfo: Window id: 0x800003 "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
---------------------------------------------------------------------------

> 3. From the output of -tree you should be able to figure out the
> window ids of the client window and the frame window:
>
> xwininfo: Window id: 0x1a00006 "~" <------- clent window id
>
> Root window id: 0x262 (the root window) (has no name)
> Parent window id: 0x402441 (has no name) <----- fram window id
> 4. Run something like this:
>
> $ sleep 10; xev -id 0x1a00006 > xev.client &
> xev -id 0x402441 > xev.frame &
> sleep 30; killall xev
>
> Within the first ten seconds, hide all windows except the
> fullscreen window. Then wait until you're sure the first sleep
> has finished, but the final sleep is not over yet, and disable
> fullscreen mode, then wait until the final sleep has completed.
> If possible, do all of this with the keyboard because movind
> the mouse generates tons of events being reported to xev, making
> the output much harder to read.

Here is the command line I used (without the linebreaks), hopefully taking the
correct ids from the outputs cited above:

sleep 10; xev -id 0x800003 > xev.client &
xev -id 0x40145d > xev.frame &
sleep 30; killall xev

And here the contents of xev.client thereafter:
---------------------------------------------------------------------------

UnmapNotify event, serial 18, synthetic NO, window 0x800003,
event 0x800003, window 0x80067b, from_configure NO

Expose event, serial 18, synthetic NO, window 0x800003,
(0,0), width 1920, height 1080, count 0

UnmapNotify event, serial 18, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, from_configure NO

FocusOut event, serial 18, synthetic NO, window 0x800003,
mode NotifyWhileGrabbed, detail NotifyAncestor

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 41425919, state PropertyNewValue

MapNotify event, serial 18, synthetic NO, window 0x800003,
event 0x800003, window 0x80067b, override NO

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x23 (WM_HINTS), time 41425919, state PropertyNewValue

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x152 (_NET_WM_STATE), time 41425919, state PropertyDelete

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x150 (_NET_WM_DESKTOP), time 41425919, state PropertyDelete

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 41425919, state PropertyNewValue

ConfigureNotify event, serial 22, synthetic YES, window 0x800003,
event 0x800003, window 0x800003, (5,23), width 1920, height 1080,
border_width 0, above 0x40145c, override NO

PropertyNotify event, serial 22, synthetic NO, window 0x800003,
atom 0x181 (_KDE_NET_WM_FRAME_STRUT), time 41425923, state PropertyNewValue

PropertyNotify event, serial 22, synthetic NO, window 0x800003,
atom 0x182 (_NET_FRAME_EXTENTS), time 41425923, state PropertyNewValue

ConfigureNotify event, serial 24, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (0,0), width 1910, height 1052,
border_width 0, above 0x0, override NO

ConfigureNotify event, serial 24, synthetic YES, window 0x800003,
event 0x800003, window 0x800003, (5,23), width 1910, height 1052,
border_width 0, above 0x40145c, override NO

ConfigureNotify event, serial 24, synthetic YES, window 0x800003,
event 0x800003, window 0x800003, (5,23), width 1910, height 1052,
border_width 0, above 0x40145c, override NO

PropertyNotify event, serial 24, synthetic NO, window 0x800003,
atom 0x181 (_KDE_NET_WM_FRAME_STRUT), time 41425927, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x800003,
atom 0x182 (_NET_FRAME_EXTENTS), time 41425927, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x800003,
atom 0x114 (WM_STATE), time 41425928, state PropertyNewValue

ReparentNotify event, serial 24, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, parent 0x8e,
(0,0), override NO

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 41425929, state PropertyNewValue

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x114 (WM_STATE), time 41425929, state PropertyDelete

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (0,0), width 1247, height 901,
border_width 0, above 0x4001be, override NO

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (409,141), width 1247, height 901,
border_width 0, above 0x4001be, override NO

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 41425935, state PropertyNewValue

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x80067b, (0,0), width 1247, height 901,
border_width 0, above 0x800004, override NO

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 41425941, state PropertyNewValue

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (409,141), width 1054, height 901,
border_width 0, above 0x4001be, override NO

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x80067b, (0,0), width 1054, height 901,
border_width 0, above 0x800004, override NO
---------------------------------------------------------------------------

And the contents of xev.frame:
---------------------------------------------------------------------------

UnmapNotify event, serial 18, synthetic NO, window 0x40145d,
event 0x40145d, window 0x800003, from_configure NO

FocusIn event, serial 18, synthetic NO, window 0x40145d,
mode NotifyWhileGrabbed, detail NotifyInferior

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 0x40145d,
(0,0), width 1920, height 1080, count 0

VisibilityNotify event, serial 18, synthetic NO, window 0x40145d,
state VisibilityPartiallyObscured

ConfigureNotify event, serial 18, synthetic NO, window 0x40145d,
event 0x40145d, window 0x40145d, (5,23), width 1920, height 1080,
border_width 0, above 0x40194e, override NO

Expose event, serial 18, synthetic NO, window 0x40145d,
(0,0), width 1910, height 23, count 1

Expose event, serial 18, synthetic NO, window 0x40145d,
(0,23), width 5, height 1029, count 0

Expose event, serial 18, synthetic NO, window 0x40145d,
(1910,0), width 5, height 1052, count 1

Expose event, serial 18, synthetic NO, window 0x40145d,
(0,1052), width 1915, height 5, count 0

ConfigureNotify event, serial 18, synthetic NO, window 0x40145d,
event 0x40145d, window 0x800003, (0,0), width 1910, height 1052,
border_width 0, above 0x0, override NO

ConfigureNotify event, serial 18, synthetic NO, window 0x40145d,
event 0x40145d, window 0x40145d, (5,23), width 1910, height 1052,
border_width 0, above 0x40194e, override NO

VisibilityNotify event, serial 18, synthetic NO, window 0x40145d,
state VisibilityUnobscured

Expose event, serial 18, synthetic NO, window 0x40145d,
(0,0), width 1910, height 1052, count 0

FocusOut event, serial 18, synthetic NO, window 0x40145d,
mode NotifyWhileGrabbed, detail NotifyNonlinear

ReparentNotify event, serial 18, synthetic NO, window 0x40145d,
event 0x40145d, window 0x800003, parent 0x8e,
(0,0), override NO

DestroyNotify event, serial 18, synthetic NO, window 0x40145d,
event 0x40145d, window 0x40145d
---------------------------------------------------------------------------

> 5. Post all the output to the mailing list.

Done.

> Ciao
>
> Dominik ^_^ ^_^
>
> --
>
> Dominik Vogt

Thank you very much again, Dominik, for attending to that issue.
I hope that the problem can be solved somehow.

Juergen

[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 0x800003 & 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: 0x800003 "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:
0x1800001 "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:
0x1800009 "MKSWindow#1": () 1225x919+0+0 +305+65
0x800004 (has no name): () 1x1+-1+-1 +-1+-1
---------------------------------------------------------------------------

while plain xwininfo said:
---------------------------------------------------------------------------
xwininfo: Window id: 0x800003 "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: 0x800003
frame ID: 0x401e6a

After

sleep 10;
{ xev -id 0x800003 & 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 0x800003, from_configure NO

FocusIn event, serial 18, synthetic NO, window 0x401e6a,
mode NotifyWhileGrabbed, detail NotifyI
UnmapNotify event, serial 18, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, from_configure NO

FocusOut event, serial 18, synthetic NO, window 0x800003,
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 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 89766065, state PropertyNewValue

MapNotify event, serial 18, synthetic NO, window 0x800003,
event 0x800003, window 0x801019, override NO

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x23 (WM_HINTS), time 89766065, state PropertyNewValue

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x152 (_NET_WM_STATE), time 89766065, state PropertyDelete

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
atom 0x150 (_NET_WM_DESKTOP), time 89766065, state PropertyDelete

PropertyNotify event, serial 18, synthetic NO, window 0x800003,
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), width 5, height 1052, count 1

ConfigureNotify event, serial 22, synthetic YES, window 0x800003,
event 0x800003, window 0x800003, (5,23), width 1920, height 1080,
border_width 0, above 0x401e69, override NO

PropertyNotify event, serial 22, synthetic NO, window 0x800003,
atom 0x181 (_KDE_NET_WM_FRAME_STRUT), time 89766068, state PropertyNewValue

PropertyNotify event, serial 22, synthetic NO, window 0x800003,
atom 0x182 (_NET_FRAME_EXTENTS), time 89766068, state PropertyNewValue

ConfigureNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x800003, (0,0), width 1910, height 1052,
border_width 0, above 0x0, override NO

ConfigureNotify event, serial 24, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (0,0), width 1910, height 1052,
border_width 0, above 0x0, override NO

ConfigureNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x401e6a, (5,23), width 1910, height 1052,
border_width 0, above 0x4030fb, override NO

VisibilityNotify event, serial 18, synthetic NO, window 0x401e6a,
state VisibilityUnobscured

Expose event, serial 18, synthetic NO, window 0x401e6a,
(0,0), width 1910, height 1052, count 0

ConfigureNotify event, serial 24, synthetic YES, window 0x800003,
event 0x800003, window 0x800003, (5,23), width 1910, height 1052,
border_width 0, above 0x401e69, override NO

ConfigureNotify event, serial 24, synthetic YES, window 0x800003,
event 0x800003, window 0x800003, (5,23), width 1910, height 1052,
border_width 0, above 0x401e69, override NO

PropertyNotify event, serial 24, synthetic NO, window 0x800003,
atom 0x181 (_KDE_NET_WM_FRAME_STRUT), time 89766075, state PropertyNewValue

PropertyNotify event, serial 24, synthetic NO, window 0x800003,
atom 0x182 (_NET_FRAME_EXTENTS), time 89766075, state PropertyNewValue

FocusOut event, serial 18, synthetic NO, window 0x401e6a,
mode NotifyWhileGrabbed, detail NotifyNonlinear

ReparentNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x800003, parent 0x8e,
(0,0), override NO

PropertyNotify event, serial 24, synthetic NO, window 0x800003,
atom 0x114 (WM_STATE), time 89766075, state PropertyNewValue

ReparentNotify event, serial 24, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, parent 0x8e,
(0,0), override NO

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 89766076, state PropertyNewValue

DestroyNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x401e6a

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x114 (WM_STATE), time 89766076, state PropertyDelete

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (0,0), width 1247, height 901,
border_width 0, above 0x4001be, override NO

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (260,72), width 1247, height 901,
border_width 0, above 0x4001be, override NO

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 89766082, state PropertyNewValue

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x801019, (0,0), width 1247, height 901,
border_width 0, above 0x800004, override NO

PropertyNotify event, serial 25, synthetic NO, window 0x800003,
atom 0x28 (WM_NORMAL_HINTS), time 89766088, state PropertyNewValue

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x800003, (260,72), width 1054, height 901,
border_width 0, above 0x4001be, override NO

ConfigureNotify event, serial 25, synthetic NO, window 0x800003,
event 0x800003, window 0x801019, (0,0), width 1054, height 901,
border_width 0, above 0x800004, override NO
---------------------------------------------------------------------------

I hope that this helps to figure out what is going on.

Any help on this issue is still heartily welcome, since I am quite clueless
about this.

Juergen

[Dominik Vogt]

On Thu, Nov 17, 2016 at 08:53:21PM +0000, 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

[Jürgen Hartmann]

Thank you, Dominik, for your answer:

> On Thu, Nov 17, 2016 at 08:53:21PM +0000, 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

[Dominik Vogt]

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

[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

[Dominik Vogt]

On Fri, Nov 18, 2016 at 10:33:20PM +0000, 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

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

from HandleMapRequestKeepRaised.

--
commit 31fcfe2130b9c3d10fd7618d4c65290b42f64f11
Author: griph <griph>
AuthorDate: Mon Dec 3 20:22:23 2007 +0000
Commit: griph <griph>
CommitDate: Mon Dec 3 20:22:23 2007 +0000

* 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

[Jürgen Hartmann]

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

[Dominik Vogt]

On Sat, Nov 19, 2016 at 03:58:26PM +0000, 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

[Jürgen Hartmann]

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

[Dominik Vogt]

On Sat, Nov 19, 2016 at 08:40:28PM +0000, 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

[Jürgen Hartmann]

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

[Dominik Vogt]

On Sun, Nov 20, 2016 at 12:30:55PM +0000, 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

[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

[Dominik Vogt]

On Sun, Nov 20, 2016 at 10:02:39PM +0000, 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

[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

[Dominik Vogt]

On Mon, Nov 21, 2016 at 12:27:45AM +0000, 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

[Jürgen Hartmann]

> 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

[Dominik Vogt]

On Mon, Nov 21, 2016 at 06:25:29PM +0000, 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

[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

[Jürgen Hartmann]

Thank you, Dominik, for this result:

> On Fri, Nov 18, 2016 at 10:33:20PM +0000, 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

[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

[Chris Siebenmann]

This post might be inappropriate. Click to display it.

[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

[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]:
<<ERROR>> 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

[Jürgen Hartmann]

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