Discussion about two new X extension proposals

[Lionel Ulmer]

Hi all,

I would like to discuss two proposals about X11 extensions (mostly related
to mouse handling) that would help the Wine project to work better. Note
that while the second is pretty Wine specific (although one could imagine
some other uses for it - like a mouse-grabbing Xnest), the first one should
be of interest for other projects (mostly games as it would come as a
replacement to the aging DGAMouse extension).

Note that in the following discussions, all names are just examples for the
sake of discussion.

Finally, if people agree on this and it would be accepted in the XOrg tree,
I would be happy to do the patch (at least to try doing the patch as my only
X11 hacking experience was to fix one or two bugs in DGA2 a long time ago
:-) ).

And now for the proposals:

 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).


 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).



Thanks,
           Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/