Discussion about two new X extension proposals

[Buola Buola]

>  I) Relative mouse movements reporting
> 
> This extension would mostly be useful for games, but it could also be useful
> for any projects that would like the user to do 'rotate' operations without
> having the user press a mouse button.
> 
> For that, I would propose the easiest solution possible: basically, the user
> could call an extension function 'XExtSetMouseEventType()' telling the X server
> that it wants, for this on-going connection, to have all 'MotionNotify'
> messages be replaces by 'RelativeMotionNotify' messages. It would be
> recommended to call this at the beginning of the session (i.e. just after
> the XOpenDisplay call to be sure that all events are of the same type)q but
> nothing prevents an application to change the type at the middle of session
> (but with no guarantee that the call has immediate effects - i.e. unflushed
> events of the new type may still be in the input queue and unaffected by the
> call to go back to the 'normal' type).
> 
> The actual message content would be exactly the same than the 'XMotionEvent'
> structure, except that it would have two (or four - see below) additionnal
> fields which would give the delta between the mouse position at the time the
> two messages were generated.
> 
> Of course these deltas would be 'real' deltas and not be constrained by the
> screen or a window (i.e. even if the mouse is at the edge of the screen or
> at the edge of a window in case of grab, it will still report deltas).
> 
> Now there is still mouse acceleration to take into account. To be versatile,
> one could imagine have two sets of deltas, one for the the unaccelerated
> values, one for the others. I have no strong opinion on that as, AFAIK, Wine
> should anyway remove mouse acceleration when needing relative mouse input
> (will have to verify that on Windows though).
> 

I think such extension would be good and also useful for me, but I
think these events shouldn't be a replacement for normal events, but
selected in a different way, such as XExtMouseSelectInput and then you
just don't select the normal MotionNotify event and have the same
behaviour as you describe
This will allow for example, for several toolkits using the same
connection and is more similar to the way most extensions work.
I don't think it's a problem to select at any moment because they are
different events so you can easily distinguish between them.


>  II) Non-exclusive mouse grabbing
> 
> This could also be called 'mouse containement'. Basically, the idea would be
> to be able to restrain the mouse to a window (like is done via
> 'XGrabPointer') but it would NOT restrict all event reporting to the
> grabbing X connection.
> 
> Basically, the problem is that Wine has a lot of different connections to
> the X server (from what I remember, one per Win32 thread). Now, if one wants
> to restrict the mouse to a window (for games for example), one really needs
> to do this from the thread that actually does the input (otherwise all mouse
> events will only go to a thread that may completely ignore them).
> 
If this is only needed for a specific project, maybe it would be
better to use synthetic mouse events and don't add rarely-used
extensions to the server (I have seen some other thread around here
looking for such things to be removed), but if more people think it
might be useful it looks ok.

regards,
   xavi