[PATCH v9 6/8] winex11.drv: Implement native mouse-movement raw-input using RawMotion.

[Derek Lesho]

To add a little bit of further clarification, the purpose of sending
normal input from rawmotion is for when we are at the edge of a clip
and WM_MOUSEMOVE events without the MOUSEEVENTF_ABSOLUTE flag are
sent, indicating the dx and dy parameters are relative.

On Thu, Aug 1, 2019 at 2:34 AM Derek Lesho <dereklesho52 at gmail.com> wrote:
>
> I just tested disabling normal input from RawMotion in oblivion, which
> uses dinput, which does not use rawinput.  Without it, I can not move
> the mouse outside of the confines of the clip even when the pointer is
> invisible / locked.  I think that relative MOUSEMOVE events are still
> supposed to be sent when the cursor is pushing up against the clip,
> which would mean we need to keep the __wine_send_input extra stuff.  I
> have the rest of the changes you requested completed and will submit
> them tomorrow as it's getting late here.
>
>
> On Wed, Jul 31, 2019 at 4:04 AM Rémi Bernon <rbernon at codeweavers.com> wrote:
> >
> > On 7/31/19 12:41 AM, Derek Lesho wrote:
> > >> AFAIU the existing RawMotion event handler was sending INPUT messages to
> > >> the server for the sole purpose of emulating and sending raw input
> > >> messages.
> > >
> > > It was my impression that MotionNotify events are ignored when the the
> > > cursor is clipped, due to some bug or problem it.  I went searching to
> > > see whether the case, and I found this:
> > > https://github.com/wine-mirror/wine/commit/0e2b4f99a9f5d97f8da0189037b7516cf1585d45#diff-c78b8a343abe990b307f178fe51c8931R332
> > >
> > > This commit came around the time they were adding raw-input, and it
> > > seems to indicate that there is a problem w/ MotionNotify on a clipped
> > > cursor, but the ignore case isn't there anymore so maybe things have
> > > changed.  Some other reasons I'm skeptical that the RawMotion code
> > > currently in place is only for rawinput events are that
> > >
> > > 1) The input is also sent as WM_MOUSEMOVE by the server, as there was
> > > no previous infrastructure to send raw-input separately and
> >
> > This commit is about warping the cursor, then ignoring the MotionNotify
> > event induced by the warp itself.
> >
> > I can see that the a pre-existing ignore case for MotionNotify events
> > while clipping is active, comes from
> > https://github.com/wine-mirror/wine/commit/8e9b4e0a5c6bee5f72ca2314db26233638f0e1d2
> > and
> > https://github.com/wine-mirror/wine/commit/da9922b40da5bc581815a4357340f3f128e8c5cb,
> > then reverted in
> > https://github.com/wine-mirror/wine/commit/9716d1c8619e5fe68d1ad3ab9a18b106499b3fac.
> >
> > About these commits, I believe that while xinput2 events are received,
> > and because they were translated as both raw input messages and normal
> > input messages, it was maybe redundant to listen to MotionNotify as
> > well. Also, the oldest commit makes me think that there could be some
> > back-and-forth movement issues if MotionNotify events are processed
> > while RawMotion events were delayed.
> >
> > Now regarding the interactions between MotionNotify and RawMotion events
> > while clipping the cursor, AFAICS MotionNotify events are still received
> > when the cursor moves but is blocked by the X11 confine window, with its
> > current position in x,y fields.
> >
> > This means that regardless if the cursor is clipped or not, both
> > MotionNotify and RawMotion events will currently get translated to raw
> > and normal input messages, the raw message position being compared to
> > the current position and converted to relative position, and the normal
> > input message position being clamped with the clipping window and not
> > sent if it is the same as the last known position (see
> > queue_hardware_message in server/queue.c and
> > https://github.com/wine-mirror/wine/commit/3909f51122ffc0f6150fa9758ba47c70dcf6b00e).
> >
> > So with the current code:
> >
> > * If the cursor moved (inside a clipping window), you get a normal input
> > message from either MotionNotify or RawMotion (which ever came first),
> > then two raw input message, one with the corresponding relative
> > movement, and another with 0x0 relative movement. The second normal
> > input message is discarded because the cursor didn't move.
> >
> > * If the cursor is clipped and blocked by confine window, Wine receives
> > (order may vary as well):
> >
> >    * a MotionNotify event with identical position, which is translated
> > to raw input message with 0x0 relative movement, but does not get
> > translated to normal input message because the cursor didn't move.
> >
> >    * a RawMotion event with some relative movement, which is translated
> > to the corresponding raw input message with relative movement, and is
> > added to current position, then clamped, and then ignored w.r.t. normal
> > input message because the clamped position is the same as the last.
> >
> > Currently if the clipping window is disabled, then no RawMotion events
> > are received anyway.
> >
> > >
> > > 2) When somebody tested warframe with my patch before I re-added
> > > mouse-movements, they had issues that were fixed by rebasing
> > > mouse-movements on my commit, and warframe does not use raw-input for
> > > the mouse.
> >
> > There could be some subtleties I may be overlooking, I will do some
> > tests. Thanks for mentioning it.
> > --
> > Rémi Bernon <rbernon at codeweavers.com>