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
>
On Mon, Nov 21, 2016 at 06:25:29PM +, 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.
> 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
On Mon, Nov 21, 2016 at 12:27:45AM +, 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 pi
> > 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
On Sun, Nov 20, 2016 at 10:02:39PM +, 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 q
> > 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
On Sun, Nov 20, 2016 at 12:30:55PM +, 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,
> 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
On Sat, Nov 19, 2016 at 08:40:28PM +, 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
> > 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
On Sat, Nov 19, 2016 at 03:58:26PM +, 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,
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
Thank you, Dominik, for this result:
> On Fri, Nov 18, 2016 at 10:33:20PM +, 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
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 (
FCheck
On Fri, Nov 18, 2016 at 10:33:20PM +, 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
> 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
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
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
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
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
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 righ
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
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 gi
> 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 vm
On Tue, Nov 15, 2016 at 01:08:08PM +, 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 variant
29 matches
Mail list logo