#162 X11 cursor position gets 'stuck'

Rootless (76)

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
wm's frame).

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
XDarwin 1.1.



  • Greg Parker

    Greg Parker - 2002-01-31

    Logged In: YES

    These are both known problems with Cocoa's mouse-moved events. 10.1 was an improvement over 10.0, and the switch to NSCarbonWindow may affect it.

  • Adrian

    Adrian - 2002-02-01

    Logged In: YES

    OK, so score -2 for Apple on this one... ;-)

    I guess it would be possible to work around it in a roughly
    similar way to OroborOSX: every so often it checks to see if
    the real cursor has moved but the X11 cursor is still where
    it was a few ticks ago. It then waits a few more ticks to see
    if the X11 cursor has still not moved. If so, it does a quick
    switch of itself into the foreground, then switches XDarwin
    back again (and posts a console message saying "X11 cursor
    Not pretty, but it does the trick.

    Would it be possible to get XDarwin to start tracking the
    cursor explicitly itself if it finds it is stuck? (And then
    stop when it gets switched from front or when it gets a
    click...) -just as a workaround for now? And even if Apple
    sort out the bugs, this code can still sit there
    harmlessly...? (Until the next mouse moved bug.)

    > the switch to NSCarbonWindow may affect it.

    Are you saying it may 'solve' it?



Log in to post a comment.