On Tue, Nov 15, 2016 at 01:08:08PM +0000, Jürgen Hartmann wrote:
> On my Linux host system (Xorg 7.6 / Kernel 3.11.6) I use Fvwm 2.6.7 as window
> manager (congratulation to the new default configuration which I like very
> much) and Vmware Workstation 9.0.4 to run virtual machines that use variants
> of MS Windows as guest operating systems.
On the site you mentioned below there are only 64-bit Linux
binaries available for download, and only for version 12. I'd
like to help, but I need a 32 bit Linux version that shows the bug
and that can actually be downloaded (i.e. I can't download
anything from the site because the download links trigger a
redirect loop).
> Now, when I switch a virtual machine that is displayed in fullscreen mode
> back to normal window mode, I get the normal Fvwm desktop but no Vmware
> window: The expected Vmware GUI window is neither visible, nor iconified
> somewhere, nor brought back by
>
> All MoveToScreen
>
> (issued in FvwmConsole), nor gets listed by FvwmWinList.
That means that the window is not mapped. WIndow managers do not
know anything about unmapped windows and can do nothing with them.
> However, according to
>
> xprop -name vmware
>
> the window still exists with the following properties
> (newlines and indents inserted for readability):
>
> WM_CLASS(STRING) = "vmware", "Vmware"
...
That just means that a window with the name still exists.
> Fvwm 2.6.7 outputs the following lines when the fullscreen mode is turned
> on (!) at the first place (newlines and indents inserted for readability):
>
> [fvwm][ComplexFunction]:
> <<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.
> [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.
Not interesting here.
> Icewm 1.2.38 comments the switching off (!) of the fullscreen mode like that
> (newlines and indents inserted for readability):
>
> IceWM: MappingNotify
> IceWM: APP BUG?
> configureRequest for window 40011C sent to destroyed frame 800003!
I'm unsure what this means exactly. It seems that icewm and
vmware disagree about the state of the client window. vmware sent
a ConfigureRequest event (moved or resized the window), and the
window was mapped at that time because otherwise icewm would not
have received the request. On the other hand the frame window
(the one with the decorations and the client window inside) did
not exist at that time, i.e. icewm had destroyed it. THat usually
happens when a window was unmapped. So, when the request arrived,
icewm thought the window was unmapped while it was actually
mapped. Although vmware might have done something funny, this
looks like an icewm bug (maybe they process events out of order).
> To summarize, here are the questions I have right now:
>
> * What is this fullscreen mode in the first place? Is it a window at all
> what we see? Is it managed by Fvwm?
Fullscreen mode is a term of the EWMH spec. There's a special
protocol to switch between fullscreen and normal modes. In
fullscreen mode the window ist displayed at maximum size without
decorations. The application can ask the window manager to switch
between modes, and the window manager may or may not do so.
> * What is that state that the hidden Vmware GUI window is in after
> returning from fullscreen mode?
> (Known to xprop, but unknown to FvwmWinList.)
It seems to be unmapped and can thus not be controlled in any way
by the window manager. To double check that you can issue
all echo $w $[w.name]
from FvwmConsole and check if the window is mentioned in the
console output. Also try
all iconify off
all windowshade off
all (vmware) resizemove 500p 500p 0p 0p
> * Is there any tool to manipulate X windows at runtime, e.g. to move or
> raise them or to change their geometry (aside from the window's border
> and the handles there--it should be applicable to a hidden window)?
That tool is fvwm. You can type any command from FvwmConsole or
using FvwmCommand from a shell. But it can only handle mapped
windows.
> * 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?
First we need to figure out what's actually happening, then we can
think about a solution.
> * Do you see any solutions, workarounds, or starting points to proceed
> with this problem?
The preferred approach would be to find a vmware version that runs
on my box, can be downloaded and shows the problem. If that's not
possible, start with gathering some information about what's
happening.
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".
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.
5. Post all the output to the mailing list.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
