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. _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
