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
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
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.
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 actuall
>> 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 t
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 wh
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 s
> 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 version
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 inter
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)&arg
> > 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 mod
> 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)&ar
> > 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 proc
> > 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 und
> Hi Tom + Jürgen,
>
> [...]
>
> I've made a fix that
> completely removes the code for the 2008 fix. Could you please
> both check out the branch dv/fix-disappering-windows from the git
> repository and check that both your problems are /still) fixed?
> The patch does fix the Vmware problem on my
> 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 e
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
>
17 matches
Mail list logo
