Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
In my last post, I described the creation of a virtual machine, saying that most of the offered setting can be left on their defaults. But when it is about to choose the guest operating system, it is better to select "Windows 3.1" than the default "Windows 7": I encountered some driver problems when booting the latter. Sorry. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you 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
>> All of this is kind of a hack. VMWare wants 100% of the mouse and >> keyboard events to go to the virtual machine without your host >> environment getting in the way, even if what you're doing normally >> has special meaning to the host. > > I see. However, if it does that, it cannot expect to be able to > communicate with the outside world, as it seems to do. Maybe this *is* the > Problem after all. > > @Jürgen: Could you try whether the attached patch helps? (It > disables all grabs during function execution and *does* break > complex functions with non-immediate actions.) I tried the patch. Unfortunately, it makes no difference to our problem. After all, the error message from Fvwm about the failed grab [fvwm][ComplexFunction]: <> Grab failed in function EWMHActivateWindowFunc, unable to execute immediate action occurs when Vmware is switched _to_ fullscreen mode. And at this stage no window is lost yet. This happens only when switching back from fullstreen to normal mode. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Previously, I mailed the output of xev for the Vmware's client and frame
windows while switching off fullscreen mode, as advised by Dominik Vogt.
Since therein there were UnmapNotify and MapNotify events on the client side
and a DestroyNotify event for the frame window, I thought that it might be
useful to have both outputs merged with the events entries being in the right
temporal order.
So I repeated the test using
sleep 10;
{ xev -id 0x83 & xev -id 0x401e6a & } > xev.client-n-frame;
sleep 30; killall xev
(without linebreaks).
Pleas note that the ID of the frame window has changed compared to my earlier
mail. This time an xwininfo -tree yielded:
---
xwininfo: Window id: 0x83 "WinVM - VMware Workstation"
Root window id: 0x8e (the root window) (has no name)
Parent window id: 0x401e6a (has no name)
2 children:
0x801019 (has no name): () 1920x1080+0+0 +0+0
2 children:
0x801ba7 (has no name): () 1512x4+176+-64 +176+-64
0x801018 (has no name): () 1920x1080+0+0 +0+0
3 children:
0x801017 (has no name): () 16x16+1227+818 +1227+818
0x800dea (has no name): () 1920x1080+0+0 +0+0
2 children:
0x800de9 "MKSSV-MKSWindowID#0": () 1440x1080+240+0 +240+0
1 child:
0x181 "MKSWindow#0": () 1440x1080+0+0 +240+0
0x800ded (has no name): () 1440x1080+240+0 +240+0
0x8010c0 "MKSSV-MKSWindowID#1": () 1225x919+305+65 +305+65
1 child:
0x189 "MKSWindow#1": () 1225x919+0+0 +305+65
0x84 (has no name): () 1x1+-1+-1 +-1+-1
---
while plain xwininfo said:
---
xwininfo: Window id: 0x83 "WinVM - VMware Workstation"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 1920
Height: 1080
Depth: 24
Visual: 0x20
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x22 (installed)
Bit Gravity State: NorthWestGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+0 -0+0 -0-0 +0-0
-geometry 1920x1080+0+0
---
So this time we have
client ID: 0x83
frame ID:0x401e6a
After
sleep 10;
{ xev -id 0x83 & xev -id 0x401e6a & } > xev.client-n-frame;
sleep 30; killall xev
the contents of xev.client-n-frame was (with surprisingly little collisions):
---
UnmapNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x83, from_configure NO
FocusIn event, serial 18, synthetic NO, window 0x401e6a,
mode NotifyWhileGrabbed, detail NotifyI
UnmapNotify event, serial 18, synthetic NO, window 0x83,
event 0x83, window 0x83, from_configure NO
FocusOut event, serial 18, synthetic NO, window 0x83,
mode NotifyWhileGrabbed, detail NotifyAncestor
KeymapNotify event, serial 18, synthetic NO, window 0x0,
keys: 0 0 0 0 48 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Expose event, serial 18, synthetic NO, window 0x401e6a,
(0,0), width 1920, height 1080, count 0
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x28 (WM_NORMAL_HINTS), time 89766065, state PropertyNewValue
MapNotify event, serial 18, synthetic NO, window 0x83,
event 0x83, window 0x801019, override NO
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x23 (WM_HINTS), time 89766065, state PropertyNewValue
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x152 (_NET_WM_STATE), time 89766065, state PropertyDelete
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x150 (_NET_WM_DESKTOP), time 89766065, state PropertyDelete
PropertyNotify event, serial 18, synthetic NO, window 0x83,
atom 0x28 (WM_NORMAL_HINTS), time 89766065, state PropertyNewValue
VisibilityNotify event, serial 18, synthetic NO, window 0x401e6a,
state VisibilityPartiallyObscured
ConfigureNotify event, serial 18, synthetic NO, window 0x401e6a,
event 0x401e6a, window 0x401e6a, (5,23), width 1920, height 1080,
border_width 0, above 0x4030fb, override NO
Expose event, serial 18, synthetic NO, window 0x401e6a,
(0,0), width 1910, height 23, count 1
Expose event, serial 18, synthetic NO, window 0x401e6a,
(0,23), width 5, height 1029, count 0
Expose event, serial 18, synthetic NO, window 0x401e6a,
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you, Dominik, for your answer: > On Thu, Nov 17, 2016 at 08:53:21PM +, Jürgen Hartmann wrote: >> Previously, I mailed the output of xev for the Vmware's client and frame >> windows while switching off fullscreen mode, as advised by Dominik Vogt. > > Please just call me Dominik. All right, I will do. >> Since therein there were UnmapNotify and MapNotify events on the client side >> and a DestroyNotify event for the frame window, I thought that it might be >> useful to have both outputs merged with the events entries being in the right >> temporal order. > > Thanks, Jürgen; I've downloaded the binary but hadn't had a chance > to try it yet. I just need some more time to do that, in the mean > time you don't need to provide more data. If the binary "works" > as expected, I'll have all the data needed. I see. Thank you for the clarification. So I will patiently await the things coming. I am really glad that you are willing to help here. Thank you very much. Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
On Thu, Nov 17, 2016 at 08:53:21PM +, Jürgen Hartmann wrote: > Previously, I mailed the output of xev for the Vmware's client and frame > windows while switching off fullscreen mode, as advised by Dominik Vogt. Please just call me Dominik. > Since therein there were UnmapNotify and MapNotify events on the client side > and a DestroyNotify event for the frame window, I thought that it might be > useful to have both outputs merged with the events entries being in the right > temporal order. Thanks, Jürgen; I've downloaded the binary but hadn't had a chance to try it yet. I just need some more time to do that, in the mean time you don't need to provide more data. If the binary "works" as expected, I'll have all the data needed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
FVWM: FvwmWiki
Hello, I have put together the various howtos, configuration examples, and so forht I have compiled over the years and updated how the wiki is built and lots of its content. You can find the wiki at http://fvwmforums.org/wiki/ Hope it finds some use. jaimos
