[PATCH] Don't alter device button maps in DoSetPointerMapping

[Thomas Jaeger]

Peter Hutterer wrote:
> On Sun, Jan 04, 2009 at 11:31:47AM -0500, Thomas Jaeger wrote:
>> I think the current behavior violates the core spec: If, say, button 1
>> is pressed on a device where it is currently disabled, but it is mapped
>> to itself on the VCP, then an XSetPointerMapping request that doesn't
>> change the mapping of button 1 will nonetheless fail.
> 
> Oh right. AFAICT, this is a leftover for when we copied the SD into the MD
> each time the SD changes. In this case, the SD's button map would be merged
> into the MD, thus overwriting the last XSetPointerMapping request (unless said
> request is also applied to the SD).
>         
> We don't do that anymore now, and the MD in fact uses a standalone mapping, so
> the approach is good. However, see below:
>> @@ -1869,7 +1856,7 @@ ProcSetPointerMapping(ClientPtr client)
>>      BYTE *map;
>>      int ret;
>>      int i, j;
>> -    DeviceIntPtr ptr = PickPointer(client);
>> +    DeviceIntPtr ptr = inputInfo.pointer;
> 
> No. PickPointer must be used here, as it return's the client's ClientPointer.
> Hardcoding the VCP means that a client may change the button mapping of the
> wrong pointer. So while this approach would work for 1.6 and master in the
> single-pointer case, it breaks once a second MD is available.

Thanks, that makes sense.  I'm attaching an updated patch that should
cleanly apply after cherry-picking commit
a85f0d6b98237d8a196de624207acf1983a1859a.