Created attachment 30922 [details] xorg.conf When using xorg-server 1.7.1, and mouse keys, the cursor location is not updated on the screen unless the cursor is hidden and shown again (for example when typing in an xterm window, or moving it somewhere where the cursor changes). Except for Driver "vesa" instead of Driver "nv" for an already reported crash, my xorg.conf (attached) is unchanged from a working 1.6.5 setup. To see this, I can start an X session, open an xterm window, maximize it, press Alt-Shift-NumLock, and try to move the mouse cursor with the arrow keys. Nothing seems to happen. I press 'a', and xterm hides the cursor. I press 4, and the cursor reappears at the correct location. I press 4 again, and the cursor doesn't move. When moving the cursor using an actual mouse, the screen gets updated correctly.
With Driver "nv" back, now that the crash is fixed, the mouse cursor does move with mouse keys. It's only with vesa that it's not moving. Unfortunately, nv is not usable even with the crash fixed, which I'll report separately later, so this bug is still an issue for me.
I'm seeing this using the "nvidia" driver on OpenSolaris with Xorg 1.7.3. (Which means silkenmouse is disabled.) Stepping through the code with a debugger I can see it going through the motions in XkbDDXFakePointerMotion(), which culminates in a call to (*pScreen->SetCursorPosition). That goes through a series of unwrappers down to this call stack miPointerSetCursorPosition() -> xf86WarpCursor() -> miPointerWarpCursor() -> miPointerMove() -> miPointerMoved() At line 478 of mipointer.c, miPointerMoved() finally gets to the point where it decides if it should update the sprite on screen, but finds that pScreenPriv->waitForUpdate is true, so it skips the update and move on. waitForUpdate seems to be set in hw/xfree86/ramdac/xf86Cursor.c to be the inverse of infoPtr->pScrn->silkenMouse. If I change XkbDDXFakePointerMotion() to set pScreenPriv->waitForUpdate to false, I get cursor updates as expected: if (pScreen->SetCursorPosition) { Bool waitForUpdate; miPointerScreenPtr pScreenPriv = GetScreenPrivate(pScreen); OsBlockSignals(); waitForUpdate = pScreenPriv->waitForUpdate; pScreenPriv->waitForUpdate = False; (*pScreen->SetCursorPosition)(inputInfo.pointer, pScreen, oldX, oldY, TRUE); pScreenPriv->waitForUpdate = waitForUpdate; OsReleaseSignals(); } but that seems grotty. It seems like most of XkbDDXFakePointerMotion() should be replacable by something like miPointerMove() anyway, but I haven't figured out how to do that.
This could be accidentally fixed by these patches: http://lists.freedesktop.org/archives/xorg-devel/2010-April/007310.html
(In reply to comment #3) > This could be accidentally fixed by these patches: > http://lists.freedesktop.org/archives/xorg-devel/2010-April/007310.html Unfortunately, it doesn't seem to be, as I can still reproduce on Xorg 1.8.1, which contains those fixes.
As noted in comment 2, this appears to be tied to the SilkenMouse state, which is off by default on Solaris/OpenSolaris. And indeed, I can cause both Xorg 1.7.4 & 1.8.1 to start updating the cursor correctly with MouseKeys via a simple xorg.conf setting of: Section "ServerFlags" Option "UseSIGIO" "true" Option "SilkenMouse" "true" EndSection
Pretty sure this is fixed with commit f0fcffe55f280add5e4db2f5e9198a48c6f1b015 Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Thu Jun 3 19:00:54 2010 -0700 Update the sprite immediately when moving it with MouseKeys please reopen if the problem is still there.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.