[PATCH 1/2] mi: Call pScreen->ConstrainCursorHarder from the position update path
daniel at fooishbar.org
Wed Jan 19 20:19:36 PST 2011
On Wed, Jan 19, 2011 at 10:59:21PM -0500, Adam Jackson wrote:
> On Jan 19, 2011, at 9:27 PM, Daniel Stone wrote:
> > On Wed, Jan 19, 2011 at 12:58:40AM -0500, Adam Jackson wrote:
> >> @@ -229,6 +229,10 @@ miPointerSetCursorPosition(DeviceIntPtr pDev, ScreenPtr pScreen,
> >> [...]
> > This looks good to me, except that now I think about it, we might need
> > CCH in _both_ miPointerSetCursorPosition, and miPointerSetPosition, or a
> > call to CCH in dix/getevents.c:positionSprite(). We do the right thing
> > in the event handling path, but without the call (direct or not) from
> > positionSprite(), we might send out constrained events, but have
> > unconstrained events recorded in the history, which is bad for any
> > clients still using pointer hints.
> Ugh. If I'm reading you right, that means pointer hints could be wrong if the
> CRTC config changes between when they're recorded and when they're sent?
> I mean I have difficulty caring too much about that, but still.
Yep. If you really cared, you could move updateHistory to be called
from UpdateDeviceState instead of GetPointerEvents, which would
eliminate the race. And if you _really_ cared, you could call
ProcessInputEvents from the top of ProcGetMotionEvents, to make sure
that clients requesting motion history still got as much history as had
been dealt with by SIGIO by the time the request got processed.
I don't think any jury would convict for not caring though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the xorg-devel