Under certain circumstances, it's possible for the
X11 cursor to become "stuck" (i.e. the position of
the X11 cursor does not change), even though
XDarwin is frontmost and the cursor is still moving.
Try this (BTW, don't use OroborOSX for these tests,
since it notices the problem and tries to resolve it):
1) Start up xeyes;
2) Make sure XDarwin is in front;
3) Command-click on a background window
belonging to another app (a Cocoa app, so it
doesn't come in front -eg; Terminal);
4) Move the cursor around and watch the eyes...
X11 cursor movement does not return until
XDarwin switches into the background then in front
again, or until a click in an X11 window (including
There are also times when the X11 cursor
appears to be "constrained" to an X11 window. i.e.
moving the cursor outside that window makes the
reported X11 position "stop" at the window's edge
(so it appears to be stuck again), but movement
returns when re-entering that or any other X11
window. Strangely enough, movement also returns
while in a Finder window (or the desktop
background, which is just a big Finder window)
and sometimes other apps (Carbon?), but will
then "get stuck" on the boundary of this app's
window if entering another (Cocoa?) app's
[i.e. for this to work, the X11 window in which it gets
constrained must have an area which overlaps
another (Cocoa?) app's window (Terminal
windows, I notice mostly), and the cursor must be
moved out of the X11 window into this area, not
into the desktop background.]
This second problem is much less common, and I
cannot find how to replicate it reliably.
Both of these problems have been apparent since
very early on (XDarwin1.0a1, even?), and are still in
Log in to post a comment.