[PATCH 1/2] mi: Call pScreen->ConstrainCursorHarder from the position update path

[Adam Jackson]

On Jan 19, 2011, at 9:27 PM, Daniel Stone wrote:
> On Wed, Jan 19, 2011 at 12:58:40AM -0500, Adam Jackson wrote:
>> Signed-off-by: Adam Jackson <ajax at redhat.com>
>> ---
>> mi/mipointer.c |    4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>> 
>> diff --git a/mi/mipointer.c b/mi/mipointer.c
>> index 554397a..1f08133 100644
>> --- a/mi/mipointer.c
>> +++ b/mi/mipointer.c
>> @@ -229,6 +229,10 @@ miPointerSetCursorPosition(DeviceIntPtr pDev, ScreenPtr pScreen,
>>     SetupScreen (pScreen);
>> 
>>     GenerateEvent = generateEvent;
>> +
>> +    if (pScreen->ConstrainCursorHarder)
>> +        pScreen->ConstrainCursorHarder(pDev, pScreen, &x, &y);
>> +
>>     /* device dependent - must pend signal and call miPointerWarpCursor */
>>     (*pScreenPriv->screenFuncs->WarpCursor) (pDev, pScreen, x, y);
>>     if (!generateEvent)
> 
> 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.

- ajax