MPX updated

[Daniel Stone]

On Mon, Dec 11, 2006 at 11:39:37AM +1030, Peter Hutterer wrote:
> On 08/12/2006, at 22:31 , Daniel Stone wrote:
> >Firstly, the number of #ifdef MPXes is kind of scary.  If it's rather
> >useful -- and requires breaking core APIs anyway -- we can just  
> >merge it
> >into the new Xi, which I've been planning for a while.  This will  
> >reduce
> >the number of new events, makes the semantics slightly less  
> >complicated,
> >and Xi is now required, so you get a grand total of zero ifdefs.   
> >Sound
> >decent?
> 
> sounds good.
> Merging into Xi will also require additions of the Xi protocol.  
> There's a few things Xi can't do now (XWarpDevicePointer or  
> XQueryDevicePointer for example).

Sure, but we can fix that.

> There is also something else: The core pointer does not send Xi  
> events. In a true multipointer setup, the core pointer should not be  
> different to the other devices. My plans were to let the core pointer  
> send MPX events as well (this would only be a few lines of code to  
> add). We need to agree on a solution here.

Hmm.  I agree that this is tricky.  Maybe the right thing to do here is
to include this in an Xi bump to protocol version 2.0, and send
DeviceMotionNotifies/etc for the core pointer as well, when a client
negotiates version 2?

> >One thing that might be interesting to chase up, as an internal
> >implementation detail, is having a struct PointerRec or so, and then
> >pointer devices can just have a pointer to the relevant PointerRec,
> >which can either be their own (for MPX devices), or the core pointer.
> >This also allows you to aggregate multiple extended devices into one
> >pointer, should you so wish -- pathological though that seems.  This
> >would, in theory, also get rid of the mpsprites global.
> 
> I'll push the SpritePtr into the DeviceIntRec and set it to the  
> correct memory when the device is initiated. That way I should get  
> rid of a lot of changes in most functions in dix. The sprite is  
> always pDev->sprite, and most of the functions in dix don't need any  
> changes except the additional parameter.

Rocking, that would be great.

> There is also a way how to optimise the sprite rendering stuff but it  
> requires a major API break (again).
> At the moment, there is a global array[MAX_DEVICES] with all the  
> information in both mipointer and misprite.
> This is a bit of a waste. In the future, I'd like to push both the  
> miCursorInfoPtr and the miPointerRec into the devPrivates of the  
> devices.
> Unfortunately, at the time when miPointer/miSpriteInitialize is  
> called, the devices do not exist yet. We would need to get a new  
> PostInitializeDevices() or something into the main. In that case, all  
> graphics drivers would need to update too,  to route it through miDC,  
> misprite up to miPointer.
> not sure whether I want to do that yet.

Maybe the cheap solution is to add it lazily: just do it in the first
call down into the pointer code.  Alternately, we could probably get a
PostInit device hook, but that would, as you say, be another ABI break
tied up with our current big one.  Probably worth doing as much ABI
breakage as we can at the same time, since it's not wildly pleasant for
distributors, and running around having to update fifteen obsolete
touchscreen drivers at the same time is heavy loss.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20061214/a628fc9d/attachment.pgp>