This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Looking for ideas to fix x2x in rootless mode...
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygwin-xfree at cygwin dot com
- Date: Thu, 31 Oct 2002 17:27:23 -0500
- Subject: Re: Looking for ideas to fix x2x in rootless mode...
- References: <F2391k0vluPCeGTX3G40000fa94@hotmail.com>
- Reply-to: cygwin-xfree at cygwin dot com
Thomas,
Your simplist fix is to add a command-line parameter to XWin.exe that
tells it to grab the Windows cursor for you and keep trapping mouse
events until the focus is given to another app via either Alt+Tab or by
clicking another app's menu on the task bar. You wouldn't be able to
``click-through'' to put the focus on Windows applications, but at least
you would be able to see those other apps in the background.
Harold
Thomas Chadwick wrote:
I'm hoping some folks on the ML might help me brainstorm a solution to
fixing x2x in rootless mode...
For those of you not familiar with x2x, it's a handy utility that gives
you a dual-headed X display if you have side-by-side workstations both
running X (one is designated the "from" display, the other the "to"
display). It does this by simply grabbing the pointer and keyboard
focus on the "from" display, and generating fake pointer and keyboard
events on the "to" display whenever it receives pointer or keyboard
events from the "from" display.
In my particular case, the "from" display is a PC running
Cygwin/XFree86, and the "to" display is an RS/6000 Workstation.
The trouble with rootless mode is that when my pointer leaves the X
server region, x2x no longer gets any pointer events from the "from"
display. This has the effect of restricting my pointer movements on the
"to" display to areas that are occupied by X clients on the "from" display.
I tried patching x2x by using the Windows API calls SetCapture(HWND
hwnd) and ReleaseCapture() at the same time x2x does XGrabPointer() and
XUnGrabPointer() respectively. However, the Capture fails. If I
interpret the MSDN documentation correctly, I think it's because the
x2x.exe thread does not own the HWND it's trying to do the Capture on
(XWin.exe does). I suppose I could try to overcome this by patching the
XGrabPointer() and XUnGrabPointer() functions in the XFree86 source
directly. This would result in XWin doing the SetCapture as a result of
calling XGrabPointer() from x2x.
I haven't actually tried this, however, because it occurs to me that I
have an additional problem. Again, if I interpret the scant
documentation properly, it looks to me that while SetCapture may grab
the pointer, clicking a mouse button while outside the X server region
will cause the capture to be released and the mouse button event to go
to whatever MS Windows client is under the pointer at the time of the
click. This would have the effect of letting me point to any region in
the "to" display as long as I don't press a mouse button. Not very useful.
Perhaps there is a different API call which keeps a "stronger" hold of
the pointer than SetCapture()?
How about calling XWarpPointer() from x2x to keep the pointer from
leaving the X server region?
Any other ideas?
_________________________________________________________________
Broadband? Dial-up? Get reliable MSN Internet Access.
http://resourcecenter.msn.com/access/plans/default.asp