Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
Thank you, Dokinik, for your assessment: > > How would you judge its behavior concerning stability and side effects: > > Would it be to risky to use it right away in a production system, aka > > "testing under wild life conditions"? > > The worst that can happen is that different windows aren't > accessible. Regarding stability, I'd say the patched code is how > it should have been from the start, but you never know what > strange and broken applications are around and how they react to > changes in the events before you just try it for a while. This > certainly needs testing. > > However, this patch only affects clients that do things like > iconifying or withdrawing their windows, i.e. the vast majority of > programs won't be affected, but you never know what closed source > programs until they break. So I will use the fixed version looking out for such a behavior of applications and report corresponding findings here. Thank you very much, Dominik, for taking care of that problem, and your profound analysis and comprehensive help. Greetings Juergen
Re: FVWM: Vmware/fvwm-2.6.7: Lost Vmware window when returning from fullscreen mode
> 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
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
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 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
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
> > 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
> 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
> > 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
