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. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
