search

libsdl-org / SDL

Simple Directmedia Layer
https://libsdl.org
zlib License
9.76k stars 1.81k forks source link

SDL_HINT_ANDROID_SEPERATE_MOUSE_AND_TOUCH on Windows? #3316

Closed SDLBugzilla closed 11 months ago

SDLBugzilla commented 3 years ago

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.9 Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2019-07-02 11:56:18 +0000, wrote:

I notice that, somehow, when locking the mouse into place(using SDL_SetRelativeMouseMode), somehow at least the movement information gets through to both mouse movement and touch movement events?

My app handles both, so when moving a touched finger accross the app(using RDP from an Android device) I see the mouse moving inside the app when it shouldn't(meaning that the touch movement is ignored properly by the app(press-location dependant) but the mouse movement is still performed due to the mouse movement events)?

On 2019-07-02 12:13:18 +0000, wrote:

Just looked at the events arriving in relative mouse mode during touch movement. I see both SDL_MOUSEMOTION events and SDL_FINGERMOTION events, which pretty much doubles (or more) all finger movements(due to receiving both)! It should only receive either SDL_FINGERMOTION or SDL_MOUSEMOTION, especially since the split hint(SDL_ANDROID_SEPERATE_MOUSE_AND_TOUCH is set(to "1")!

On 2019-07-02 12:25:24 +0000, wrote:

Just did some more testing. It also applies to the mouse buttons! Pressing anywhere on the window also presses the left mouse button(through a SDL_MOUSEBUTTONDOWN) even though it's in touch RDP mode! So clearly mouse and touch events are handled double in all cases(when touching), while my app requires them seperated, like on Android.

It isn't even a special case either. Although my computer doesn't have a touch screen(I'm using Windows RDP on Android for that), there are Windows computers that do have one, perhaps even with mice as well!

So not seperating mouse and keyboard on other devices than Android clearly IS a problem when supporting touch as well as mouse inputs! Since my app handles both in a compatible way, it's SDL2 that's reporting too much in this case, messing up input!

On 2019-07-02 17:45:50 +0000, wrote:

Is that perhaps related to the SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS and their issues on Android?

On 2019-07-02 19:40:32 +0000, Cameron Gutman wrote:

Does ignoring events from SDL_TOUCH_MOUSEID not work for you?

From https://wiki.libsdl.org/SDL_MouseMotionEvent

which may be SDL_TOUCH_MOUSEID, for events that were generated by a touch input device, and not a real mouse. You might want to ignore such events, if your application already handles SDL_TouchFingerEvent.

On 2019-07-02 21:04:49 +0000, wrote:

Just added code to ignore the mouse events for ignoring when event->button.which==SDL_TOUCH_MOUSEID and event->motion.which==SDL_TOUCH_MOUSEID, but although button presses and releases for touch events now no longer occur, mouse movement still does? Although I do see that event->motion.which is 0(which would indicate it's the same as the normal Windows mouse ID)?

Perhaps there's an issue with generating touch to mouse movement events there, generating ID of 0 or mouse ID instead of SDL_TOUCH_MOUSEID?

On 2019-07-02 21:57:25 +0000, wrote:

OK. This is interesting behaviour(moving one finger on the screen once):

  • When not using relative mouse mode, finger movement is reported for a MouseID of 0. The buttons aren't triggered(filtered away by a MouseID of SDL_TOUCH_MOUSEID).
  • When using relative mouse mode, it triggers mouse press, mouse movement, mouse release, sometimes even mouse movement following it. All are for MouseID of 0.

That's strange...

On 2019-07-02 23:12:41 +0000, wrote:

Perhaps it's some strange touch-related behaviour by the Microsoft RDP app for Android instead of the applocation itself? Could it be that the Android app for RDP is just sending mouse events to the computer, which the SDL2 app just processes(which would explain why the MouseID is 0; the same as the normal mouse input)?

On 2019-07-03 01:10:55 +0000, Cameron Gutman wrote:

Can you try setting SDL_HINT_MOUSE_RELATIVE_MODE_WARP to 1 and see if that works around the issue? I may have seen something similar.

On 2019-07-03 03:22:47 +0000, Cameron Gutman wrote:

Created attachment 3856 Patch to ignore synthetic mouse events for touchscreens

I tracked this one down today. The problem is that Windows tries to be helpful behind our back and create some raw mouse events for the touchscreen (presumably for older apps that don't handle WM_TOUCH). We reported those as regular mouse events, so it led to the double reporting where some events would sneak in without SDL_TOUCH_MOUSEID via WM_INPUT, in addition to those we received through the WM_TOUCH codepath.

There appears to be a separate issue when SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1 that still causes some spurious motion (unsure if mouse motion or touch motion at this point), but the attached patch addresses the default SDL_HINT_MOUSE_RELATIVE_MODE_WARP=0 case.

I'm going to try to track down the SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1 issue and I'll post another patch if I figure it out.

On 2019-07-03 09:43:21 +0000, Sam Lantinga wrote:

I'm a little concerned that this patch will break injected input using SendInput()

Cameron, can you check that?

On 2019-07-03 11:52:08 +0000, wrote:

Something related I've found: http://the-witness.net/news/2012/10/wm_touch-is-totally-bananas/

Perhaps it has something to do with the solution?

On 2019-07-03 12:48:52 +0000, wrote:

Hmmmm... The MOUSEEVENTF_FROMTOUCH case only being for WM_LBUTTONDOWN and WM_LBUTTONUP is confirmed by MSDN: https://docs.microsoft.com/en-us/windows/desktop/wintouch/troubleshooting-applications

But I see it already being used further up in the file?

Perhaps a combination of the two?

/ Mouse data (ignoring synthetic mouse events generated for touchscreens) / if ((inp.header.dwType == RIM_TYPEMOUSE) && (!((inp.header.hDevice == NULL) && ((GetMessageExtraInfo() & 0x82) == 0x82)))) {

That way, the NULL device special case will only work when it's combined with the extra info's special bits being set(according to the (un)documented documentation), thus making it handle the NULL case for the hDevice as well when used by the SendInput method(as it will never have those 0x82 bits set)?

On 2019-07-03 13:04:07 +0000, wrote:

Well, looking at MSDN some more (and googling for it), I found the following: https://docs.microsoft.com/nl-nl/windows/desktop/tablet/system-events-and-mouse-messages

The value returned from GetMessageExtraInfo needs to be mask-checked against 0xFFFFFF00, and then compared with 0xFF515700. The following definitions may make this clearer:

define MI_WP_SIGNATURE 0xFF515700

define SIGNATURE_MASK 0xFFFFFF00

define IsPenEvent(dw) (((dw) & SIGNATURE_MASK) == MI_WP_SIGNATURE

If the comparison is true, then this mouse message was generated by a Tablet PC pen or touch screen. In all other cases, you can assume that this message was generated by a mouse device.

The lower 8 bits returned from GetMessageExtraInfo are variable. Of those bits, 7 (the lower 7, masked by 0x7F) are used to represent the cursor ID, zero for the mouse or a variable value for the pen ID. Additionally, in Windows Vista, the eighth bit, masked by 0x80, is used to differentiate touch input from pen input (0 = pen, 1 = touch).

So that confirms the 0x80 bit to be correct(for Vista and up). So the lower 7 is the cursor ID. So instead of 0x82 it should actually be 0x80?

On 2019-07-03 13:05:57 +0000, wrote:

So the combination would be: / Mouse data (ignoring synthetic mouse events generated for touchscreens) / if ((inp.header.dwType == RIM_TYPEMOUSE) && (!((inp.header.hDevice == NULL) && ((GetMessageExtraInfo() & 0x80) == 0x80)))) {

On 2019-07-03 13:29:15 +0000, wrote:

Or, documented even better(according to MSDN): //Check for Windows Vista and up first, to be able to get bit 7 of the GetMessageExtraInfo or ignore it! DWORD version = GetVersion(); DWORD major = (DWORD) (LOBYTE(LOWORD(version))); DWORD minor = (DWORD) (HIBYTE(LOWORD(version)));

int is_vista; is_vista = (major > 6) || ((major == 6) && (minor >= 0)); //Are we at least Windows Vista(able to use bit 7 of the GetMessageExtraInfo() result)? //Versions below Vista will set the low 7 bits to the Mouse ID and don't use bit 7.

/ Mouse data (ignoring synthetic mouse events generated for touchscreens) / if ((inp.header.dwType == RIM_TYPEMOUSE) && (!((inp.header.hDevice == NULL) && ((GetMessageExtraInfo() & ((0xFFFFFF00)|(is_vista?0x80:0x00))) == (0xFF515700|(is_vista?0x80:0x00)))))) { //Check bits 8-32 for the signature. Only check bit 7 when Vista and up(Cleared=Pen, Set=Touch).

On 2019-07-03 13:46:00 +0000, wrote:

Hmmm... Thinking some more about the lower 7-bits(the case of them being zeroed):

//Check for Windows Vista and up first, to be able to get bit 7 of the GetMessageExtraInfo or ignore it! DWORD version = GetVersion(); DWORD major = (DWORD) (LOBYTE(LOWORD(version))); DWORD minor = (DWORD) (HIBYTE(LOWORD(version)));

int is_vista; is_vista = (major > 6) || ((major == 6) && (minor >= 0)); //Are we at least Windows Vista(able to use bit 7 of the GetMessageExtraInfo() result)? //Versions below Vista will set the low 7 bits to the Mouse ID and don't use bit 7.

DWORD extrainfo = GetMessageExtraInfo(); //Extra info! / Mouse data (ignoring synthetic mouse events generated for touchscreens) / if ((inp.header.dwType == RIM_TYPEMOUSE) && (!((inp.header.hDevice == NULL) && (((extrainfo&0x7F)&&(is_vista?(extrainfo&0x80):1))||((extrainfo & 0xFFFFFF00) == 0xFF515700))))) { //Check bits 8-32 for the signature(which will indicate a Tablet PC Pen or Touch Device). Only check bit 7 when Vista and up(Cleared=Pen, Set=Touch(which we need to filter out)), when the signature is set. The Mouse ID will be zero for an actual mouse.

That should be the most compatible?

On 2019-07-03 15:25:50 +0000, wrote:

After some fixing code: //Check for Windows Vista and up first, to be able to get bit 7 of the GetMessageExtraInfo or ignore it! DWORD version = GetVersion(); DWORD major = (DWORD)(LOBYTE(LOWORD(version))); DWORD minor = (DWORD)(HIBYTE(LOWORD(version)));

      int is_vista;
      is_vista = (major > 6) || ((major == 6) && (minor >= 0)); //Are we at least Windows Vista(able to use bit 7 of the GetMessageExtraInfo() result)?
      //Versions below Vista will set the low 7 bits to the Mouse ID and don't use bit 7.

      LPARAM extrainfo = GetMessageExtraInfo(); //Extra info!
      /* Mouse data (ignoring synthetic mouse events generated for touchscreens) */
      if ((inp.header.dwType == RIM_TYPEMOUSE) && (!((inp.header.hDevice == NULL) && (((extrainfo & 0x7F) && (is_vista ? (extrainfo & 0x80) : 1)) || ((extrainfo & 0xFFFFFF00) == 0xFF515700))))) { //Check bits 8-32 for the signature(which will indicate a Tablet PC Pen or Touch Device). Only check bit 7 when Vista and up(Cleared=Pen, Set=Touch(which we need to filter out)), when the signature is set. The Mouse ID will be zero for an actual mouse.

On 2019-07-03 18:10:06 +0000, wrote:

Hmmm... After a lot of testing, I've found out that while my code is correct(it's calculating properly), based on Cameron's patch(by observing compiler results and generated mouse button/movement events).

But, the check for the added hDevice variable being NULL for touch events (even with and without my added checks) clearly isn't enough. RDP's touch events still bubble through to the mouse events when testing using Windows 10 + Android's Microsoft RDP program:/

On 2019-07-03 20:03:56 +0000, wrote:

Hmmmm... Even changing the last line to ... if ((inp.header.dwType == RIM_TYPEMOUSE) && (!((inp.header.hDevice == NULL) || (((extrainfo & 0x7F) && (is_vista ? (extrainfo & 0x80) : 1)) || ((extrainfo & 0xFFFFFF00) == 0xFF515700))))) { //Check bits 8-32 for the signature(which will indicate a Tablet PC Pen or Touch Device). Only check bit 7 when Vista and up(Cleared=Pen, Set=Touch(which we need to filter out)), when the signature is set. The Mouse ID will be zero for an actual mouse.

... Doesn't have any effect on the events. Perhaps it's required for the mouse events as well?

On 2019-07-03 20:58:03 +0000, wrote:

Created attachment 3859 Improvements for the improved mouse vs touch detection.

I've added some more checks to the mouse events as well, using the same algorithm for the mouse events as well as the previous patch, using the WM_INPUT event as a base for a simple function to be used for mouse events as well(having a result of 0(invalid(touch), ignore this input) or 1(valid(handle this input as a mouse move/button event), the first parameter being an object for the WM_INPUT event and NULL for the mouse events), but I still see the events arriving into my application no matter what?

I've based it off the current commit(https://hg.libsdl.org/SDL/rev/b5cd5e1e4440), downloaded as a zip file into a and b(although edited in another directory), then ran "diff -u -w a/src/video/windows/SDL_windowsevents.c b/src/video/windows/SDL_windowsevents.c>SDL_windowsevents_filterv1.diff" from the MinGW command prompt for a simple diff. Although no support for the repository, though(I use Smartgit, which doesn't seem to be that compatible?).

On 2019-07-04 18:40:16 +0000, wrote:

OK. Found something interesting with my patch. When I use it as it's uploaded, the algorithm fails and all events get through.

But, when I remove the "(inp->header.hDevice==NULL) || " part, the algorithm starts working partially. In relative mode, the mouse events are all successfully ignored on the app side(the algorithm(with hDevice removed from the filter) is working properly.

But when not in relative mode, only the movement events still pass through? Perhaps you can shed some light on that?

On 2019-07-04 21:21:52 +0000, wrote:

Created attachment 3860 Improvements for the improved mouse vs touch detection.

I managed to get it fully working over RDP. Checked the mouse events on both touch and non-touch cases and both in relative and normal mode.

It seems to be fully working, as long as the SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS hints are both set to 0. I noticed that once either or both aren't 0(at least one of those(either or both) must be the case, as adding code that sets them both to 0(for my application's case) fixes the issue that was mentioned in my previous posts with the strange movement event when not in relative mode). The old case was that neither hint was set at all.

So perhaps that remaining problem is somewhere in the code that handles those events? Thinking logically, as they're the only code affected by those hints, my code can't be the issue. It's functioning as it should. It's the code that handles those touch-mouse and mouse-touch translations that creates issues by default settings.

On 2019-07-04 21:36:47 +0000, wrote:

Digging into the SDL_hints.h reveals which of the cases is the troublemaker:

By default SDL will generate mouse events for touch events

So the issue is that by default, SDL will generate mouse events for touch events, thus somehow generating the mouse movement event only?

On 2019-07-04 22:27:46 +0000, wrote:

So, as far as I can see, the issue only occurs when the TOUCH_MOSUE the SDL_TOUCH_MOUSEID seems to be zero when it's supposed to be SDL_TOUCH_MOUSEID.

When disabling the translation using the SDL_HINT_TOUCH_MOUSE_EVENTS to 0, the event where event.motion.which==SDL_HINT_TOUCH_MOUSE_EVENTS doesn't happen, because the translation is disabled, thus not generating any motion events.

So the SDL_HINT_TOUCH_MOUSE_EVENTS=1 movement event isn't properly filling the event.motion.which variable(leaving it set to 0)? Or perhaps during the creation of the event object...

On 2019-07-04 22:29:59 +0000, wrote:

(In reply to superfury from comment # 24)

So, as far as I can see, the issue only occurs when the TOUCH_MOSUE the SDL_TOUCH_MOUSEID seems to be zero when it's supposed to be SDL_TOUCH_MOUSEID.

Whoops, a little mistake in my post. I meant:

So, as far as I can see, the issue only occurs when the SDL_TOUCH_MOUSEID seems to be zero when it's supposed to be SDL_TOUCH_MOUSEID.

On 2019-07-04 23:00:33 +0000, wrote:

So, when the flag is set(the default on Windows, when it's generating invalid events), mouse input is simulated from touch input.

The hardware layer itself already removes the duplicate events, so that's clearly not the case(demonstrated by the setting of the flag to "0" in my app).

So one of the layers after it, until it reaches the pushevent handlers should have a problem during it's path from the touch interpretation.

Looking at the handlers(src/events/SDL_touch.c line 263 and 377 are clearly the start of the possible causes that cause this issue.

On 2019-07-05 00:36:39 +0000, wrote:

Created attachment 3861 Test logging added to the SDL_mouse and SDL_touch modules.

Something is definitely going wrong, looking at the main event handling for movement, during the SDL_PrivateSendMouseMotion, it's caller SDL_SendMouseMotion from the touch events.

I get a kind of weird log: CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... The thread 0x3dec has exited with code 0 (0x0). CRITICAL: Starting touch motion emulation... CRITICAL: Starting mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: CallingSendMouseMotion for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for warp) for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 4294967295... CRITICAL: Core mouse motion event(dropped due to no change state) for mouseID 4294967295... CRITICAL: Finished touch motion emulation... CRITICAL: Starting touch button press emulation... CRITICAL: Finished touch button press emulation... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Aborted mouse motion event for mouseID 00000000... The thread 0x6144 has exited with code 0 (0x0). CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... The thread 0x5d94 has exited with code 0 (0x0). The thread 0x3778 has exited with code 0 (0x0). The thread 0x2f58 has exited with code 0 (0x0). The thread 0x4144 has exited with code 0 (0x0). The thread 0x29c has exited with code 0 (0x0). The thread 0x6308 has exited with code 0 (0x0). The thread 0x441c has exited with code 0 (0x0). The thread 0x2ac0 has exited with code 0 (0x0). The thread 0x29fc has exited with code 0 (0x0). The thread 0xc94 has exited with code 0 (0x0). The thread 0x208c has exited with code 0 (0x0). The thread 0x33b4 has exited with code 0 (0x0). The thread 0xfe8 has exited with code 0 (0x0). The thread 0x20 has exited with code 0 (0x0). The thread 0x1c70 has exited with code 0 (0x0). The thread 0x22d4 has exited with code 0 (0x0). The thread 0x6d0 has exited with code 0 (0x0). The thread 0x61a4 has exited with code 0 (0x0). The thread 0x6180 has exited with code 0 (0x0). The thread 0x492c has exited with code 0 (0x0). The thread 0x3c7c has exited with code 0 (0x0). The thread 0x6018 has exited with code 0 (0x0). The thread 0x2ce8 has exited with code 0 (0x0). The thread 0x3920 has exited with code 0 (0x0). The thread 0x5f34 has exited with code 0 (0x0). The thread 0x3bc8 has exited with code 0 (0x0). The thread 0x5f08 has exited with code 0 (0x0). The thread 0x54e0 has exited with code 0 (0x0). The thread 0x31e8 has exited with code 0 (0x0). The thread 0x381c has exited with code 0 (0x0). The thread 0x1fe8 has exited with code 0 (0x0). The thread 0x5394 has exited with code 0 (0x0). The thread 0x2428 has exited with code 0 (0x0). The thread 0x1a30 has exited with code 0 (0x0). The thread 0x5554 has exited with code 0 (0x0). The thread 0x10a0 has exited with code 0 (0x0). The thread 0x45ec has exited with code 0 (0x0). The thread 0x5ca0 has exited with code 0 (0x0). The thread 0x5818 has exited with code 0 (0x0). The thread 0x48cc has exited with code 0 (0x0). The thread 0x4324 has exited with code 0 (0x0). The thread 0x5484 has exited with code 0 (0x0). The thread 0x2c54 has exited with code 0 (0x0). The thread 0x49c8 has exited with code 0 (0x0). The thread 0x5868 has exited with code 0 (0x0). The thread 0x1aa4 has exited with code 0 (0x0). The thread 0x68c has exited with code 0 (0x0). The thread 0x23ac has exited with code 0 (0x0). The thread 0x4e0c has exited with code 0 (0x0). The thread 0x3708 has exited with code 0 (0x0). The thread 0x15e4 has exited with code 0 (0x0). The thread 0x2ab8 has exited with code 0 (0x0). The thread 0x36e8 has exited with code 0 (0x0). The thread 0x3450 has exited with code 0 (0x0). The thread 0x5a5c has exited with code 0 (0x0). The thread 0x3828 has exited with code 0 (0x0). The thread 0x4c68 has exited with code 0 (0x0). The thread 0x27d8 has exited with code 0 (0x0). The thread 0x4f8c has exited with code 0 (0x0). The thread 0x49f0 has exited with code 0 (0x0). The thread 0x42c0 has exited with code 0 (0x0). The thread 0x201c has exited with code 0 (0x0). CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Starting touch motion emulation... CRITICAL: Starting mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: CallingSendMouseMotion for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for warp) for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 4294967295... CRITICAL: Core mouse motion event(dropped due to no change state) for mouseID 4294967295... CRITICAL: Finished touch motion emulation... CRITICAL: Starting touch button press emulation... CRITICAL: Finished touch button press emulation... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Starting touch motion emulation... CRITICAL: Starting mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: CallingSendMouseMotion for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for warp) for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 4294967295... CRITICAL: Core mouse motion event(dropped due to no change state) for mouseID 4294967295... CRITICAL: Finished touch motion emulation... CRITICAL: Starting touch button press emulation... CRITICAL: Finished touch button press emulation... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000...

That's for a few times trying to move touch input over the apps window(stroking a finger(touch events) over it during RDP on Android in touch mode).

On 2019-07-05 08:01:29 +0000, wrote:

Just found out something REALly interesting!

The events that ARE getting through from the non-simulated mouse movements are actually SDL_UpdateMouseFocus synthesizing a mouse move event on gain&move and move&focus lost events simulations!

CRITICAL: WM_ACTIVATE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_ACTIVATE: Finished real mouse motion event! 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\oleacc.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\TextInputFramework.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\d3d9.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumdx.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cryptsp.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\rsaenh.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\bcrypt.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvd3dumx.dll'. Cannot find or open the PDB file. The thread 0x49c has exited with code 0 (0x0). 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ResourcePolicyClient.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\ResourcePolicyClient.dll' 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\AudioSes.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ninput.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.829_none_fb46a5473061b9d5\comctl32.dll'. Cannot find or open the PDB file. CRITICAL: Starting touch motion emulation... CRITICAL: Starting mouse motion event for mouseID 4294967295... CRITICAL: SDL_UpdateMouseFocus: synthesizingfocus gain & move event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizingfocus gain & move event! CRITICAL: CallingSendMouseMotion for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for warp) for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 4294967295... CRITICAL: Core mouse motion event(dropped due to no change state) for mouseID 4294967295... CRITICAL: Finished touch motion emulation... CRITICAL: Starting touch button press emulation... CRITICAL: Finished touch button press emulation... CRITICAL: WM_MOUSELEAVE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: SDL_UpdateMouseFocus: synthesizing move & focus lost event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizing move & focus lost event! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_MOUSELEAVE: Finished real mouse motion event! CRITICAL: WM_ACTIVATE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_ACTIVATE: Finished real mouse motion event! CRITICAL: SDL_UpdateMouseFocus: synthesizingfocus gain & move event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizingfocus gain & move event! CRITICAL: WM_MOUSELEAVE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: SDL_UpdateMouseFocus: synthesizing move & focus lost event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizing move & focus lost event! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_MOUSELEAVE: Finished real mouse motion event! CRITICAL: WM_ACTIVATE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_ACTIVATE: Finished real mouse motion event! The thread 0x5b0c has exited with code 0 (0x0). CRITICAL: Starting touch motion emulation... CRITICAL: Starting mouse motion event for mouseID 4294967295... CRITICAL: SDL_UpdateMouseFocus: synthesizingfocus gain & move event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizingfocus gain & move event! CRITICAL: CallingSendMouseMotion for mouseID 4294967295... CRITICAL: Core mouse motion event for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for warp) for mouseID 4294967295... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 4294967295... CRITICAL: Core mouse motion event(dropped due to no change state) for mouseID 4294967295... CRITICAL: Finished touch motion emulation... CRITICAL: Starting touch button press emulation... CRITICAL: Finished touch button press emulation... CRITICAL: WM_MOUSELEAVE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: SDL_UpdateMouseFocus: synthesizing move & focus lost event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizing move & focus lost event! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_MOUSELEAVE: Finished real mouse motion event! CRITICAL: WM_ACTIVATE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_ACTIVATE: Finished real mouse motion event! CRITICAL: SDL_UpdateMouseFocus: synthesizingfocus gain & move event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizingfocus gain & move event! CRITICAL: WM_MOUSELEAVE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: SDL_UpdateMouseFocus: synthesizing move & focus lost event! CRITICAL: Core mouse motion event for mouseID 00000000... CRITICAL: Core mouse motion event(checking for warp) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for relative coordinate being 0) for mouseID 00000000... CRITICAL: Core mouse motion event(checking for enabled) for mouseID 00000000... CRITICAL: MouseMotionEvent for mouseID 00000000! CRITICAL: MouseMotionEvent for mouseID 00000000=00000000! CRITICAL: SDL_UpdateMouseFocus: Finished synthesizing move & focus lost event! CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_MOUSELEAVE: Finished real mouse motion event! CRITICAL: WM_ACTIVATE: real mouse motion event! CRITICAL: Starting mouse motion event for mouseID 00000000... CRITICAL: Aborted mouse motion event for mouseID 00000000... CRITICAL: WM_ACTIVATE: Finished real mouse motion event! The thread 0x46e4 has exited with code 0 (0x0).

On 2019-07-05 08:18:43 +0000, wrote:

OK. Adding logging to both the previous two modules as well as the various functions calling the mouse movement event handler, I see that two REAL cases are calling mouse movement events for the user(through SDL_UpdateMouseFocus): WM_MOUSELEAVE and WM_ACTIVATE.

WM_ACTIVATE doesn't trigger an event. WM_MOUSELEAVE DOES trigger an event, even though the real mouse didn't move!

On 2019-07-05 09:11:35 +0000, wrote:

Created attachment 3862 Test logging added to the SDL_mouse and SDL_touch and sdl_windowsevents modules.

This is what happens during touch events.

As can be seen, the mouseleave events are messing up touch?

On 2019-07-05 10:14:49 +0000, wrote:

So, somehow, touch to mouse movement translation makes the mouse move out of the window somehow, while it shouldn't?

On 2019-07-05 11:59:44 +0000, wrote:

Tried the check function on it. It doesn't seem to have any effect, the function always returns 1(meaning no information about any touch event).

So why is Windows sending the WM_MOUSELEAVE event for each touch event on RDP?

On 2019-07-05 12:22:04 +0000, wrote:

Thinking about it, why DOES mouseleave report an mouse movement event? Doesn't mouse movement itself handle that already?

On 2019-07-05 12:46:26 +0000, wrote:

After thinking some more... Does it really matter that mouse motion is reported leaving the window with said combination(touch to mouse events, not relative mode and moving(using touch to mouse) outside the window). Is there software that requires the absolute/relative coordinates to be valid when that happens?

On 2019-07-05 12:48:37 +0000, wrote:

Hmmm... Perhaps just report it as the touch to mouse ID when the functionality is enabled only, otherwise ID of 0?

On 2019-07-05 14:35:26 +0000, wrote:

Created attachment 3863 Test logging added to the SDL_mouse and SDL_touch and sdl_windowsevents modules v2.

I've improved the code a bit, adding a simple check when mouse motion is generated. When it notices that it's generating mouse motion for a simulated event, the flag is set to SDL_TRUE, otherwise SDL_FALSE.

Now the WM_MOUSELEAVE event handler checks for said flag. If it's set, it's assumed it could be a simulated event that triggered the mouseleave. Then it just checks if the flag is set. If it's cleared, the old mousemotion event handler is called(with a mouseID of 0).

However, if it finds the flag set(usually means that it's processing the invalid event), it verifies that the sdl_touch_mouse_events is set(to make sure it's really a touch event causing this, which happens always with touch movements). If it's set, it sends an mouseID of SDL_TOUCH_MOUSEID and clears the flag, otherwise it sends a mouseID of 0(the legacy case).

The SDL_LogCritical calls is still left in there to observe the events being fired and handled for testing. Of course you should remove those when not wanting the logs anymore(when it's verified and working).

I've left them in there so you people could take a look. Is the approach working in your cases as well?

The c files go to their usual places(src/events, except the sdl_windowsevents.c, which goes to the src/video/windows folder). Since I use Visual Studio Community 2017 for those files, the tabs on the modified parts may be a bit off(I see that the original code seems to have four spaces instead, but the C++ editor I'm using will just change them to tabs no matter what).

On 2019-07-05 18:24:32 +0000, wrote:

Created attachment 3864 Improvements for the improved mouse vs touch detection.

Non-debug version of the patch for the new mouse vs touch detection.

On 2019-07-05 18:26:38 +0000, wrote:

Created attachment 3865 Improvements for the improved mouse vs touch detection.

Debug version of the patch for the new mouse vs touch detection.

On 2019-07-05 18:29:39 +0000, wrote:

Both versions seem to have the issue with tabs vs space characters. I couldn't get Visual Studio Community 2017 to properly save those, but you guys can probably easily fix that, when needed

On 2019-07-06 15:33:17 +0000, wrote:

Any chance this could make it into 2.0.10, if it's verified to be working at your sides? It would really help with a lot of issues(concerning input) I've been having while using RDP(as well as others using RDP and touch screens in general).

On 2019-07-07 17:23:58 +0000, Ryan C. Gordon wrote:

I'm sort of nervous about the size of this patch for 2.0.10. I think this should wait.

--ryan.

On 2019-07-07 18:10:23 +0000, Ozkan Sezer wrote:

Created attachment 3868 cleaned-up patch

I cleaned-up your patch for whitespace so that it's more readable, also simplified the vista-or-newer detection and made it decided at RegisterApp() time, not everytime checkMousePacketTouch() called (see the new attachment.)

Noticed a weird thing: your checkMousePacketTouch() always returns the same result whether inp in NULL or not: so what is actually the point in there??

On 2019-07-07 18:17:23 +0000, wrote:

There used to be in the original code(it's a leftover of Cameron's patch which was also taken into account(but it doesn't work, so I removed it(that check) when finding that out)). That argument to the function can now be removed(together with the if(inp) check and it's conditional execution). It was a leftover of the original code I had added based on Cameron's "(hDevice!=NULL)" patch. That no longer applies, as it doesn't work at all.

The bottom line directly after the if (inp) { ... } (THISHERE) should still stay, as it's the core of the touch detection.

So only lines 387-389 and the first parameter to the function should be removed(and all it's calls should have only the second parameter remain, the first being removed from it's arguments within the event handlers).

On 2019-07-07 18:30:39 +0000, Cameron Gutman wrote:

I think this bug is different (or at least a superset of) the behavior I was seeing with a physical touchscreen. I opened up a different bug with the smaller change that fixed the issue for me. Simply checking the touch bit in GetMessageExtraInfo() is sufficient for my repro case.

https://bugzilla.libsdl.org/show_bug.cgi?id=4713

On 2019-07-07 18:33:40 +0000, wrote:

You're forgetting something important there: bit 7 is ONLY valid on Windows Vista and newer(according to Microsoft's documentation). So your code WILL fail on older Windows versions(XP and below?).

On 2019-07-07 18:42:09 +0000, Ozkan Sezer wrote:

Created attachment 3870 cleaned-up patch (# 2)

@superfury: further cleaned-up patch attached. (build-tested only.)

On 2019-07-12 20:52:30 +0000, wrote:

The cleaned-up code should still work as far as I can see. Since the code looks fine (unchanged except for the Vista detection) and compiles without issues.

There's still one little thing I noticed, at least with Visual Studio Community 2019: the call to detect Windows Vista is indicated as being deprecated (the call to getVersion). Is there perhaps a better way to do that(Detect Vista and up)? Otherwise, it's working like a charm here(testing with a Android phone running RDP to the Windows 10 computer).

On 2019-07-12 22:00:50 +0000, Ozkan Sezer wrote:

(In reply to superfury from comment # 47)

deprecated (the call to getVersion).

Yes deprecated, but it's blah, at least for detecting vista and older as far as I know.

Is there perhaps a better way to do that(Detect Vista and up)?

Yes: #include and call IsWindowsVistaOrGreater() The macros and the function calls in there are supported for win2000 and newer, if I remember correctly.

On 2019-07-12 22:06:04 +0000, wrote:

Is that also compatible with any of SDL2's targeted compilers? Afaik the project for Visual Studio uses an old toolchain (v100). Would that work on those too(and other compilation targets like MinGW and perhaps others)?

On 2019-07-12 22:06:53 +0000, wrote:

And of course for all Windows OSes SDL2 is made for?

On 2019-07-12 22:34:10 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 41)

I'm sort of nervous about the size of this patch for 2.0.10. I think this should wait.

This sounds like it's gotten some scrutiny, though...Sam, should we sneak this in for 2.0.10?

--ryan.

On 2019-07-14 23:44:29 +0000, Sam Lantinga wrote:

This generally looks okay and seems to have gotten a reasonable amount of review.

One suggestion on the cleaned up patch # 2, change checkMousePacketTouch() so it's more clear that it's getting the extra info:

static LPARAM GetMessageExtraInfoAndCheckMousePacketTouch(SDL_bool checkTouch) { LPARAM extrainfo = GetMessageExtraInfo(); / Mouse data (ignoring synthetic mouse events generated for touchscreens) / / Versions below Vista will set the low 7 bits to the Mouse ID and don't use bit 7: Check bits 8-32 for the signature(which will indicate a Tablet PC Pen or Touch Device). Only check bit 7 when Vista and up(Cleared=Pen, Set=Touch(which we need to filter out)), when the signature is set. The Mouse ID will be zero for an actual mouse. / checkTouch = (!(((extrainfo & 0x7F) && (is_vista ? (extrainfo & 0x80) : 1)) || ((extrainfo & 0xFFFFFF00) == 0xFF515700))) ? SDL_TRUE : SDL_FALSE; return extrainfo; }

On 2019-07-15 07:21:28 +0000, Ozkan Sezer wrote:

Created attachment 3880 cleaned-up patch (# 3, after Sam's review)

Attached a new version after Sam's review with further cosmetic clean-ups. Kept the type of checkTouch as int instead of SDL_bool because of negative negative value checks.

Compile-tested only. Needs a re-review / test I guess.

On 2019-07-15 16:45:34 +0000, Sam Lantinga wrote:

This is added for 2.0.10, thanks! https://hg.libsdl.org/SDL/rev/49190e92b7d1

On 2019-07-15 18:15:59 +0000, Ozkan Sezer wrote:

(In reply to Sam Lantinga from comment # 54)

This is added for 2.0.10, thanks! https://hg.libsdl.org/SDL/rev/49190e92b7d1

Cameron Gutman and superfury should re-test in their environments to make sure that the intended fixes work and nothing else is broken.

On 2019-07-16 04:55:53 +0000, Cameron Gutman wrote:

I tested my scenario again:

  • With SDL_HINT_MOUSE_RELATIVE_MODE_WARP=0 (default), it's still okay (same behavior as after bug 4713 was fixed)
  • With SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1, I'm still seeing spurious motion events like before the patches, so no change here either.

This is the event dump from a tap on my touchscreen with SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1: INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44026 windowid=2 which=4294967295 state=0 x=1919 y=1074 xrel=0 yrel=0) INFO: SDL EVENT: SDL_MOUSEBUTTONDOWN (timestamp=44027 windowid=2 which=4294967295 button=1 state=pressed clicks=1 x=1919 y=1074) INFO: SDL EVENT: SDL_FINGERDOWN (timestamp=44027 touchid=258344443 fingerid=158 x=0.600520 y=0.563888 dx=0 dy=0 pressure=1.000000) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44032 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=193 yrel=69) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44054 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=193 yrel=69) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44068 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=193 yrel=69) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44084 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=193 yrel=69) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44090 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=0 yrel=1) INFO: SDL EVENT: SDL_FINGERMOTION (timestamp=44091 touchid=258344443 fingerid=158 x=0.600520 y=0.564814 dx=0 dy=0.000925 pressure=1.000000) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44098 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=193 yrel=71) INFO: SDL EVENT: SDL_FINGERMOTION (timestamp=44099 touchid=258344443 fingerid=158 x=0.600520 y=0.565740 dx=0 dy=0.000925 pressure=1.000000) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44114 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=0 yrel=1) INFO: SDL EVENT: SDL_FINGERMOTION (timestamp=44115 touchid=258344443 fingerid=158 x=0.600520 y=0.566666 dx=0 dy=0.000925 pressure=1.000000) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44120 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=193 yrel=72) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44128 windowid=2 which=4294967295 state=1 x=1919 y=1079 xrel=0 yrel=1) INFO: SDL EVENT: SDL_FINGERMOTION (timestamp=44129 touchid=258344443 fingerid=158 x=0.600520 y=0.567592 dx=0 dy=0.000925 pressure=1.000000) INFO: SDL EVENT: SDL_MOUSEBUTTONUP (timestamp=44134 windowid=2 which=4294967295 button=1 state=released clicks=1 x=1919 y=1079) INFO: SDL EVENT: SDL_FINGERUP (timestamp=44135 touchid=258344443 fingerid=158 x=0.600520 y=0.567592 dx=0 dy=0 pressure=1.000000) INFO: SDL EVENT: SDL_MOUSEMOTION (timestamp=44147 windowid=2 which=0 state=0 x=1919 y=1079 xrel=193 yrel=69)

The last SDL_MOUSEMOTION comes in with which=0 and causes the spurious motion. I suspect it may have to do with the mouse warping itself. Those repeated (193, 69) motions definitely smell synthetic (and we got many of them with SDL_TOUCH_MOUSEID before finally getting one with which=0).

Sam, do you want a new bug for this or shall we continue here?

On 2019-07-16 05:53:18 +0000, Sam Lantinga wrote:

Let's continue here. Do you have a patch for your issue?

On 2019-07-16 09:32:47 +0000, wrote:

Just been looking through the SDL code... I only see a few other places that generate mouse motion>

  • The WM_ACTIVATE handling. I doubt this is the cause?
  • SDL_WarpMouseInWindow: Highly suspicious. Probably the cause in your case?

Looking at the function(SDL_WarpMouseInWindow), it completely ignores any synthesized events, just sending movement from the REAL mouse without checks!

On 2019-07-16 10:56:43 +0000, wrote:

Just looked through the SDL code for possible causes of Cameron's relative mouse mode warp issue:

  • SDL_OnWindowFocusGained (called from SDL_WINDOWEVENT_FOCUS_GAINED event handler)

  • SDL_RestoreMousePosition:1341&1321 (called from SDL_updateFullscreenMode, SDL_OnWindowHidden(<-), SDL_OnWindowMinimized(<-), SDL_OnWindowRestored(fullscreenonly))

  • SDL_SetRelativeMouseMode, probably not, only called once by the app? Not executed when not changing.

  • SDL_PrivateSendMouseMotion:364 probably not, seeing as the mouseid is filtered out for touch events?

The SDL_OnWindowFocusGained seems a highly likely cause, seeing as it blindly causes a warp to the current position(not checking for changed coordinates). Remember, I noticed that releasing the finger from the screen somehow caused a focus lost and then a focus gained event back when testing? Perhaps it's related?

SDL_SetRelativeMouseMode shouldn't be the cause, seeing as it's executed when it changed state(enabled parameter changes).

Also, mouse.c:354, is that valid(when taking into account the order it's checks are executed in)? Won't it be counted as "mouseID != (SDL_TOUCH_MOUSEID && mouse->relative_mode_warp)" by the compiler?

On 2019-07-16 11:18:37 +0000, wrote:

Also, one little question, are you in relative mode or not when this happens?

What happens if you move the was_touch_mouse_events check from line 455 to before line 384?

Like this:

} else {
    xrel = x - mouse->last_x;
    yrel = y - mouse->last_y;
}

/* Set us pending (or clear during a normal mouse movement event) as having triggered */
mouse->was_touch_mouse_events = (mouseID == SDL_TOUCH_MOUSEID) ? SDL_TRUE : SDL_FALSE;

/* Drop events that don't change state */
if (!xrel && !yrel) {

ifdef DEBUG_MOUSE

    printf("Mouse event didn't change state - dropped!\n");

endif

    return 0;
}

If that fixed it, the WM_MOUSELEAVE fix wasn't taking all the packets into account(most of them, except when not moving). That would explain why there is no mouse movement at least, as well as the event being triggered?

On 2019-07-16 11:56:16 +0000, wrote:

Having modified that part of my last post(the moving up of the check for last events to before the (xrel|yrel)!=0 check, I only see the mouse movement getting through for non-synthesized events in ONE case: when toggling the relative mouse mode OFF using a touch input handling(in my own app)! Any touches seem to properly fall through(by the check if it's from a real mouse, e.g. the SDL_TOUCH_MOUSEID) and abort the handler.

The only touch cases that seem to get through to the actual handler(thus using a mouseID of 0) happen when the app itself DISABLES relative movement using SDL_SetRelativeMouseMode(SDL_FALSE) ! That might be a hint to the remainder of the issue!

On 2019-07-16 13:25:06 +0000, wrote:

OK, having added some logs, I can now confirm that the strange mouse warps aren't caused by the SDL_SetRelativeMouseMode itself directly(no idea about the mouse itself though).

Looking at the logs after adding debugger logging to the SDL mouse code, I can now definitely confirm the cause of it is purely the WM_MOUSEMOVE, WM_ACTIVATE and WM_MOUSELEAVE SDL2 event handlers!

Looking in my logs, I only see three kinds of events firing actual mouse movement handlers in the user app(with touch input only, the locations that I've reported is in the file without the logging added or the moving of ): "WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM", which is SDL_windowsevents:519 "WM_ACTIVATE: MouseMotionToCURSORPOSXY", which is SDL_windowsevents:480 "WM_MOUSELEAVE: MouseMotionToCURSORPOSXY!", which is SDL_windowsevents:650

Those three locations are the only ones still triggering mouse movement events in the user app.

On 2019-07-16 13:26:23 +0000, wrote:

The full log for explanation:

'UniPCemu_x64.exe' (Win32): Loaded 'X:\projects\projects_build\UniPCemu\UniPCemu_x64.exe'. Symbols loaded. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\win32u.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32full.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp_win.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\winmmbase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'X:\projects\projects_build\UniPCemu\SDL2_net.dll'. Symbols loaded. 'UniPCemu_x64.exe' (Win32): Loaded 'X:\projects\projects_build\UniPCemu\SDL2.dll'. Symbols loaded. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cfgmgr32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\setupapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ws2_32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\rpcrt4.dll' 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\rpcrt4.dll' 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\shell32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\IPHLPAPI.DLL'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\SHCore.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\version.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\combase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\bcryptprimitives.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\windows.storage.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\shlwapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\profapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\powrprof.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\fltLib.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ole32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\oleaut32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\uxtheme.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\dwmapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\MMDevAPI.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\devobj.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\propsys.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\avrt.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\dinput8.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\InputHost.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\WinTypes.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\CoreMessaging.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\CoreUIComponents.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ntmarta.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\hid.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\wintrust.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msasn1.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\crypt32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\XInput1_4.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\winsta.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'. Cannot find or open the PDB file. CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\oleacc.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\TextInputFramework.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\d3d9.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumdx.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cryptsp.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\rsaenh.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\bcrypt.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvd3dumx.dll'. Cannot find or open the PDB file. The thread 0x4bb4 has exited with code 0 (0x0). 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ResourcePolicyClient.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\ResourcePolicyClient.dll' 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\AudioSes.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\wdmaud.drv'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ksuser.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.drv'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\midimap.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.UI.dll'. Cannot find or open the PDB file. The thread 0x44b0 has exited with code 0 (0x0). CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ninput.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.829_none_fb46a5473061b9d5\comctl32.dll'. Cannot find or open the PDB file. CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED The thread 0x2c28 has exited with code 0 (0x0). CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 0,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 0,0 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: Mouse motion event from: 0: 485,663 CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 0,0 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 274,263 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: -126,-37 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! CRITICAL: Mouse motion event from: 0: -70,-280 CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 204,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 0,0 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 204,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: -196,-300 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! CRITICAL: Mouse motion event from: 0: 15,-14 CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 219,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 0,0 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 219,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: -181,-300 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! CRITICAL: Mouse motion event from: 0: 5,-24 CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 0,0 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 224,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: -176,-300 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! CRITICAL: Mouse motion event from: 0: 6,-18 CRITICAL: WM_MOUSELEAVE: MouseMotionToCURSORPOSXY! FINISHED CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED The thread 0x3c78 has exited with code 0 (0x0). The thread 0x23f0 has exited with code 0 (0x0). The thread 0x2840 has exited with code 0 (0x0). The thread 0x66f0 has exited with code 0 (0x0). 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\XInput1_4.dll' The thread 0x1780 has exited with code 0 (0x0). The thread 0x37e8 has exited with code 0 (0x0). The thread 0x3ad8 has exited with code 0 (0x0). The thread 0x3088 has exited with code 0 (0x0). The thread 0x5b28 has exited with code 0 (0x0). The thread 0x5cdc has exited with code 0 (0x0). The thread 0x2444 has exited with code 0 (0x0). The thread 0x578c has exited with code 0 (0x0). The thread 0x2df8 has exited with code 0 (0x0). The thread 0x567c has exited with code 0 (0x0). The thread 0x4df0 has exited with code 0 (0x0). The thread 0x58bc has exited with code 0 (0x0). The thread 0x3b8 has exited with code 0 (0x0). The thread 0x3274 has exited with code 0 (0x0). The thread 0x5184 has exited with code 0 (0x0). The program '[24276] UniPCemu_x64.exe' has exited with code 0 (0x0).

On 2019-07-16 13:44:01 +0000, wrote:

Interesting through: the WM_ACTIVATE and WM_MOUSELEAVE events handlers disappear when the application isn't losing focus to the debugger(because a breakpoint has hit). So disabling said breakpoint removed those from the event trigger list.

Then, the only SINGLE mouse motions that still make it through are those from WM_MOUSEMOVE, to be exact, the XPARAM,YPARAM one (SDL_windowsevents:519).

Full log without breakpoints: 'UniPCemu_x64.exe' (Win32): Loaded 'X:\projects\projects_build\UniPCemu\UniPCemu_x64.exe'. Symbols loaded. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\win32u.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'X:\projects\projects_build\UniPCemu\SDL2_net.dll'. Symbols loaded. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\winmm.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'X:\projects\projects_build\UniPCemu\SDL2.dll'. Symbols loaded. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\gdi32full.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msvcp_win.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ws2_32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\setupapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\winmmbase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cfgmgr32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cfgmgr32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\cfgmgr32.dll' 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\shell32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\SHCore.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\IPHLPAPI.DLL'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\combase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\version.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\bcryptprimitives.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\windows.storage.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\shlwapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\kernel.appcore.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\profapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\powrprof.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\fltLib.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ole32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\oleaut32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\uxtheme.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\dwmapi.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\clbcatq.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\MMDevAPI.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\propsys.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\devobj.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\avrt.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\dinput8.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\InputHost.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\CoreMessaging.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\WinTypes.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\CoreUIComponents.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ntmarta.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\hid.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\wintrust.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msasn1.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\crypt32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\XInput1_4.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\winsta.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'. Cannot find or open the PDB file. CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! CRITICAL: WM_ACTIVATE: MouseMotionToCURSORPOSXY! FINISHED 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\oleacc.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\TextInputFramework.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\d3d9.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvldumdx.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\imagehlp.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cryptsp.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\rsaenh.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\bcrypt.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\cryptbase.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_7a39871618b19f06\nvd3dumx.dll'. Cannot find or open the PDB file. The thread 0x4ddc has exited with code 0 (0x0). 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ResourcePolicyClient.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\ResourcePolicyClient.dll' 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\AudioSes.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\wdmaud.drv'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ksuser.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.drv'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\msacm32.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\midimap.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\Windows.UI.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\System32\ninput.dll'. Cannot find or open the PDB file. 'UniPCemu_x64.exe' (Win32): Loaded 'C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.829_none_fb46a5473061b9d5\comctl32.dll'. Cannot find or open the PDB file. The thread 0x4550 has exited with code 0 (0x0). CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 0,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 0,0 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 0,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: -400,-300 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 0,0 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: -400,-300 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being enabled and focused FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 106,-62 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED The thread 0xacc has exited with code 0 (0x0). CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: -191,-300 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: Mouse motion event from: 0: 174,42 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED The thread 0x6d0 has exited with code 0 (0x0). The thread 0x381c has exited with code 0 (0x0). The thread 0x57a0 has exited with code 0 (0x0). The thread 0x5cb0 has exited with code 0 (0x0). 'UniPCemu_x64.exe' (Win32): Unloaded 'C:\Windows\System32\XInput1_4.dll' CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled to 174,42 CRITICAL: SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED The thread 0x281c has exited with code 0 (0x0). The thread 0x6324 has exited with code 0 (0x0). The thread 0xfd4 has exited with code 0 (0x0). The thread 0x3a84 has exited with code 0 (0x0). The thread 0x6174 has exited with code 0 (0x0). The thread 0xc90 has exited with code 0 (0x0). The thread 0x2654 has exited with code 0 (0x0). The thread 0x164 has exited with code 0 (0x0). The thread 0x4ae8 has exited with code 0 (0x0). The thread 0x419c has exited with code 0 (0x0). The thread 0x556c has exited with code 0 (0x0). The thread 0x50f0 has exited with code 0 (0x0). The thread 0x10bc has exited with code 0 (0x0). The thread 0x5dc8 has exited with code 0 (0x0). The thread 0x4838 has exited with code 0 (0x0). The program '[19844] UniPCemu_x64.exe' has exited with code 0 (0x0).

So, somehow, some events are getting through the GetMessageExtraInfoAndCheckMousePacketTouch check for some weird reason?

On 2019-07-16 14:04:32 +0000, wrote:

Created attachment 3881 Input events SDL receives from Windows during touch-only application usage.

Just added a bit of logging for the checking the input data of the GetMessageExtraInfoAndCheckMousePacketTouch function... The results are once again interesting.

This reveals something interesting about the GetMessageExtraInfo function. It seems that somehow, it sometimes returns 0 for it's result when delivering it's FINAL packet after having streamed one or more touch packets! So the solution to that is simple: keep remembering if the last movement packet was a touch packet. If it's a touch packet, ignore the 0 result and count it as a touch packet anyways(for WM_MOUSEMOVE only). Otherwise, handle normally. So once again(just like the WM_MOUSELEAVE handler), use a state handler to check if it's for a touch packet and handle it normally if it isn't, clearing the flag in the process.

On 2019-07-16 15:18:45 +0000, wrote:

Created attachment 3882 Improvements for the improved mouse vs touch detection v3.

I've made some additions to the checking of real/touch mouse movements. This filters out the invalid trailing 0 during touch input(counted and checked against for WM_MOUSEMOVE only).

This seems to properly get rid of the remainder of invalid touch input being reported as mouse events.

On 2019-07-16 15:23:21 +0000, wrote:

Created attachment 3883 Improvements for the improved mouse vs touch detection v3 - debugger version.

And of course a version with debugging output being dumped.

Both the debugger and non-debugger ones needs cleanup for neat code, but of course my editor(Visual Studio Community 2019) won't be able to do that(due to the tabs problem mentioned earlier).

You can both check it out if it works in your cases as well.

Is it running properly in your cases as well?

On 2019-07-17 07:33:14 +0000, Cameron Gutman wrote:

I'm seeing an infinite stream of messages as soon as I move the mouse or touch the screen that persists forever after I stop:

CRITICAL: GetMessageExtraInfoAndCheckMousePacketTouch: extrainfo=00000000 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! - 1280 720 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center - 1280 720! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED CRITICAL: GetMessageExtraInfoAndCheckMousePacketTouch: extrainfo=00000000 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! - 1280 720 CRITICAL: WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM! FINISHED CRITICAL: WM_MOUSEMOVE: Relative mode warp to center - 1280 720! CRITICAL: WM_MOUSEMOVE: Relative mode warp to center! FINISHED

That's making it hard to figure out what's going on with the touchscreen. Something in the WM_MOUSEMOVE processing appears to be generating more WM_MOUSEMOVEs or something.

What OS are you testing on? I'm on Win10 1903.

On 2019-07-17 11:43:32 +0000, wrote:

My OS is currently Windows 10 Pro 1803, as the modern control panel tells me. Does that mean my OS didn't update properly?

Of course each of the GetMessageExtraInfoAndCheckMousePacketTouch being logged is a new Windows event handler being handled(seeing as the mouse button handlers won't handle it again when it's already handled by the WM_MOUSEMOVE handler due to the variable not being <0(actually -1) anymore).

And the rest of the handling log after that in your example is the event handler doing it's different mouse move events(or trying to send them to the application).

You can see the actual mouse events being acnowledged as movement and sent to the app as a SDL Mouse Move event(through getEvent etc.) by looking for the rows saying "Mouse motion event from:" followed by the mouse ID, then xrel and yrel coordinates).

On 2019-07-17 12:52:48 +0000, wrote:

All those different WM_MOUSEMOVE events being logged are the different steps within the WM_MOUSEMOVE handler, at which it reports the handlers being fired that potentially cause mouse movement events to be reported to the application.

For mouse moves caused by the WM_MOUSEMOVE event handler itself, this can happen at various places:

  • GetMessageExtraInfoAndCheckMousePacketTouch reports what Windows tells it about the event handler and if it skipped the packet due to being a finished packet(GetMessageExtraInfoAndCheckMousePacketTouch with Windows information logged always. "WASTOUCH" is logged after that if it detects it to be a touch event, otherwise "ISFINALTOUCH extrainfo=%08X" when it detects the finishing invalid packet that finishes the touch packet stream(and after that 0 in the extra info is normally taken as REAL mouse packets again)). This is logged for all Windows handlers that use said information in it's handling to filter out touch packets from the REAL mouse packets.

  • WM_ACTIVATE etc. reports their mouse movement handlers being sent to the application potentially(depending on whether or not the SendMouseMotionEvent ignores it or not).

  • Now, the mouse move event handler has multiple cases(after the above extra info check reports it's a REAL mouse, thus returning 1 in checkTouch) that it logs(as either can produce mouse motion events for the user):

    • "WM_MOUSEMOVE: Relative mode warp to XPARAM,YPARAM!" : This reports the "SDL_SendMouseMotion(data->window, 0, 0, GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam));" being called from the WM_MOUSEMOTION handler. This always happens with real mouse motion detected packets.
    • "WM_MOUSEMOVE: Relative mode warp to center!" : Reports when a warp to the center of the window is executed(due to the Windows 10 Fall Creators update, bug 3931)

WM_INPUT has multiple places that reports mouse motion events as well, depending on the circumstances and settings of the app. So of course those are logged as well. And of course WM_MOUSELEAVE as well.

Each of the events being logged has both an entry point(before the function is called) and return point(after the function returns) being logged, kept apart with it's finished or started by a FINISHED being added to the end of the output for said identifier(one exception to that, but it's still unique enough to keep the start and finished apart, at "SDL_SetRelativeMouseMode: Warping mouse to the enter of the window because of being focused and disabled FINISHED" that's not reporting the mouse x and y locations as well).

The main point of both start and end functions being logged is so that, when a SDL mouse event is sent to the application, the cause of the event can easily be identified.

If you see the WM_MOUSEMOVE events kept being streamed in an infinite non-stop stream when not moving the mouse, that's probably Windows for some reason sending an unending stream to the application, that's not SDL's fault(unless SDL messes with Windows' settings?).

On 2019-07-21 12:05:23 +0000, wrote:

I'm not sure if this is somehow related, but when I try to move the REAL mouse(from another computer connected using RDP) out of the window, somehow SDL doesn't keep the mouse within the window properly, causing it to reach the border of the full screen and stop reporting mouse movements?

This seems to happen both when setting the SDL_HINT_MOUSE_RELATIVE_MODE_WARP to 1 and to 0? Or perhaps it doesn't happen with "0", but something else is causing troubles, preventing the reporting of mouse movement when reaching the border of the window in windowed mode?

It looks like the patch made in this bug doesn't fix that, nor has any effect on that issue? So I doubt this issue is the direct source of that problem? It only filters the touch movements, not the real mouse movements, which is causing issues in this case.

One of the causes seems to be that the mouse reaches the border of the screen, preventing more input from being generated in relative mouse mode?

On 2019-07-21 12:10:49 +0000, wrote:

Yup. Just confirmed part of it. When I enable the warp option, when enabling relative mouse mode and moving the mouse out of the window(in windowed mode), the mouse is actually OUT OF THE WINDOW when disabling it. Thus it can end up at the edge of the screen, causing the mouse not to respond properly to input past said edge anymore!

On 2019-07-21 12:28:43 +0000, wrote:

Again, looking at the xrel and yrel values in the mouse motion events, it looks like it reports a relative screen location compared to the center of the window? So x,y=center of window, xrel,yrel=Position of the mouse compared to the center of the window.

But since the mouse isn't kept in the center of the window properly(or in this case NOT AT ALL) after each and every mouse movement reports the absolute position of the mouse compared to the center of the window! That isn't supposed to happen I think, especially since the mouse is supposed to be warped back to the center of the window(which is how it's calculating movement, by monitoring movement from the center of the window, where it assumes the mouse will be!).

So for some reason, mouse warping to the center of the window if failing when using SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1?

On 2019-07-21 12:50:11 +0000, wrote:

Just added some logging to SDL itself. It seems to be trying to warp the mouse back to some location(warping the mouse to the center of the window), but somehow failing to do so?

Adding some simple logging of the coordinates it has at said location and the location it's trying to warp to shows that it isn't warping the mouse at all!

So the call to SDL_WarpMouseInWindow is completely failing!

On 2019-07-21 13:21:17 +0000, wrote:

The SetCursorPos call is succeeding(it seems, according to it's result) and reports a result of 1(TRUE) in BOOL format, but the mouse isn't actually warped to the location!

Now, the question is: is this due to RDP using an external mouse uncontrollable by Windows, or is the cause somewhere within Windows itself? Hmmm...

On 2019-07-21 13:39:38 +0000, wrote:

Just confirmed RDP vs non-RDP input. When RDP isn't used, the method works as it should(the warping succeeds in all aspects and relative motion is reported as it should). The mouse can't leave the window when it's in relative mode properly.

BUT, when RDP is used, the warping is reported as having succeeded, the mouse can easily leave the window and when at the edge of the screen won't report further mouse events!

Now the question is, can it be solved by SDL, or is the Microsoft RDP having issues with it(not properly updating mouse state locations when in relative mode)?

On 2019-07-21 20:12:01 +0000, Ozkan Sezer wrote:

(In reply to Ozkan Sezer from comment # 55)

https://hg.libsdl.org/SDL/rev/49190e92b7d1

Cameron Gutman and superfury should re-test in their environments to make sure that the intended fixes work and nothing else is broken.

(In reply to Cameron Gutman from comment # 56)

I tested my scenario again:

  • With SDL_HINT_MOUSE_RELATIVE_MODE_WARP=0 (default), it's still okay (same behavior as after bug 4713 was fixed)
  • With SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1, I'm still seeing spurious motion events like before the patches, so no change here either.

I'm lost among 70-something comments. My simple question is: If the above commit didn't change anything after the fix for bug 4713 (that's what I understood - correct?), what have we gained from it, why should we keep it?

On 2019-07-21 21:04:55 +0000, wrote:

Well, you might misunderstand what's been going on. All the patches I've given (including the v2&v3 ones combined) fixed the bugs what the 'fix' in bug 4713 didn't fix at all(in fact, it's bugfix 4713 that's not working at all, espescially on Windows versions not supporting bit 7(all pre-Vista OSes) in which it will fully fail). Also, according to the Microsoft documentation, just relying on said bit is wrong, as that can theoretically also include a mouse(when the value of the low byte is 0x80), as it states the low 7 bits being 0 for a mouse, besides failing on pre-Vista. When using the combined v2(already in hg) and v3(additions for the remaining cases of v2; not in hg yet) patches from this thread, the filtering between works 100% in successfully filtering and seperating the duplicate events(no more touch to mouse events from Windows get through anymore).

It's bug 4713 that's not working at all, and as far as it's working it's only on Vista and up.

What happened with the warp=1 case is fixed with the v3 addition(in my test code I added to my SDL2 program). It's just that Cameron hasn't replied yet if it's working in his case after I've posted the fix. It's running like a charm(not taking the different bug that has to do with mouse warping not working with RDP into account).

My v2 and v3 diffs combined fully fix the problem that this thread was about (seperating touch and mouse events properly during touch and mouse input through RDP). Mouse cursor warping not working is an entirely different issue, but I was just wondering if anyone knew something about it(not related to the input filters themselves).

On 2019-07-21 21:10:07 +0000, wrote:

Also, I'm on build 1803(Windows 10 Pro)? Did you mean 1803(a typo) instead of 1903? Afaik I'm on the most recent one?

On 2019-07-22 11:07:24 +0000, wrote:

@Ozkan Oh, did you mean whether to keep the fix of bug 4713? The bugfixes(in hg) of the v2 patch in this thread already overwrite said code(v3 adds some other bugfixes), so it's already not in hg anymore?

On 2019-07-22 11:09:26 +0000, wrote:

Also, I found out that somehow Windows 10 Pro doesn't update from 1803 to 1903, so I assumed it was the most recent one. I'll test the SDL patches again when Windows is ready and I have time to check it.

On 2019-07-22 11:21:45 +0000, Ozkan Sezer wrote:

(In reply to superfury from comment # 80)

@Ozkan Oh, did you mean whether to keep the fix of bug 4713?

No.

On 2019-07-22 12:08:39 +0000, wrote:

So you meant the fixes within the v2 patches of this bug? But in my testcase, v2+v3 combined (v3 applied after v2 in the hg repository) fixes all the issues I have with SDL2 and mouse movement. If you would undo that commit in hg, most problems will return(about 51% of the issues with inout seperation) as well as having a buggy implementation of the bit7 check!

On 2019-07-22 12:25:21 +0000, Ozkan Sezer wrote:

(In reply to superfury from comment # 83)

[...] If you would undo that commit in hg, most problems will return(about 51% of the issues

That's what I asked: what did http://hg.libsdl.org/SDL/rev/49190e92b7d1 fixed apart from the bug 4713 already fixed: A really short, itemized clear list, not something spanning 80 comments.

On 2019-07-22 13:30:48 +0000, wrote:

What http://hg.libsdl.org/SDL/rev/49190e92b7d1 fixed is most of the events that were all slipping through with bug 4713. Bug 4713 did not work at all in my case. Also, Bug 4713's patch will break 100% on pre-Vista(XP) OSes, while my code follows the Microsoft documentation on checking the bits from the Windows function(GetMessageExtraInfo) as Microsoft actually documents it(instead of relying on the Vista and up existing bit(also checked for XP OSes, at which point(running on Windows XP) it will not identify anything correctly(as XP doesn't set that bit accordingly), misdiagnosing everything(since the docs mention the combination of bits 0-6 and bit 7 to identify mouse on both bit7=0 and bit7=1(depending on bits 0-6 being 0=mouse, otherwise touch/pen input) according to Microsoft documentation. It also doesn't checks the ID(bits 8-31) which WILL also be set according to documentation in the case for Pen/Touch input(another case that will fail with bug 4713). The patches in this thread does actually take those cases into account, as well as providing bugfixes for the other handlers that are affected by the issue that aren't even checked against in bug 4713(unfiltered WM_MOUSELEAVE, WMMOUSEMOVE and WM (mousebuttons) events causing further issues).

To be simple: The patches in this bug(bug 4704) actually check as Microsoft Documents it and fixes other related issues as well, while bug 4713 doesn't fix the related issues at all(only one very very(~1 out of 256 possible inputs actually accounted for), and relies purely on undocumented behaviour on pre-Vista OSes(and will probably still not work at all in the cases mentioned in this post, depending on Microsoft's code and version of said code in the OS(undocumented XP behaviour, if not random)).

On 2019-07-22 13:51:25 +0000, wrote:

very very=>very very little part(the world for editable comments!).

On 2019-07-22 14:49:07 +0000, Cameron Gutman wrote:

(In reply to superfury from comment # 85)

What http://hg.libsdl.org/SDL/rev/49190e92b7d1 fixed is most of the events that were all slipping through with bug 4713. Bug 4713 did not work at all in my case. Also, Bug 4713's patch will break 100% on pre-Vista(XP) OSes,

The patch doesn't affect XP and earlier positively or negatively. They simply don't set bit 7. XP-based tablet PCs are over 10 years old and were not popular at the time anyway, so I'm not losing much sleep over leaving that unfixed.

while my code follows the Microsoft documentation on checking the bits from the Windows function(GetMessageExtraInfo) as Microsoft actually documents it(instead of relying on the Vista and up existing bit(also checked for XP OSes, at which point(running on Windows XP) it will not identify anything correctly(as XP doesn't set that bit accordingly), misdiagnosing everything(since the docs mention the combination of bits 0-6 and bit 7 to identify mouse on both bit7=0 and bit7=1(depending on bits 0-6 being 0=mouse, otherwise touch/pen input) according to Microsoft documentation. It also doesn't checks the ID(bits 8-31) which WILL also be set according to documentation in the case for Pen/Touch input(another case that will fail with bug 4713). The patches in this thread does actually take those cases into account, as well as providing bugfixes for the other handlers that are affected by the issue that aren't even checked against in bug 4713(unfiltered WM_MOUSELEAVE, WMMOUSEMOVE and WM (mousebuttons) events causing further issues).

The traditional WM_ mouse event code was already checking for MOUSEEVENTF_FROMTOUCH (0xFF515700) prior to either of our patches. With https://hg.libsdl.org/SDL/rev/49190e92b7d1 now, we're checking against MOUSEEVENTF_FROMTOUCH twice. I never saw evidence in my testing that just checking for MOUSEEVENTF_FROMTOUCH was insufficient for the non-raw input messages. Did you see messages where the top bytes were 0xFF515700 but the bottom byte was actually zero? If not, I think the multiple checks in GetMessageExtraInfoAndCheckMousePacketTouch() are overkill and we should just use the existing single MOUSEEVENTF_FROMTOUCH check (and potentially add it on WM_MOUSELEAVE).

Only WM_INPUT lacked such a check, but my testing indicated that simply looking for MOUSEEVENTF_FROMTOUCH was not sufficient. The reference at http://the-witness.net/news/2012/10/wm_touch-is-totally-bananas/ was useful and supported the idea that MOUSEEVENTF_FROMTOUCH was not sufficient for checking WM_INPUT. My solution was similar based on the solution there, however 0x82 required all pointer IDs to be even to function properly. In my case, I was also getting odd pointer IDs, hence the check being reduced to 0x80.

I'm not opposed to changing the check to 0x7F != 0 which would suffice for Vista too and not check "undocumented bits" on XP. The MSDN docs clearly state the lower 7 bits are 0 for mice, so it shouldn't matter whether the pen/touch bit 0x80 is set.

(In reply to superfury from comment # 76)

Just confirmed RDP vs non-RDP input. When RDP isn't used, the method works as it should(the warping succeeds in all aspects and relative motion is reported as it should). The mouse can't leave the window when it's in relative mode properly.

BUT, when RDP is used, the warping is reported as having succeeded, the mouse can easily leave the window and when at the edge of the screen won't report further mouse events!

Now the question is, can it be solved by SDL, or is the Microsoft RDP having issues with it(not properly updating mouse state locations when in relative mode)?

RDP (like VNC and similar tools) uses absolute coordinates for mouse motion. You can't warp the mouse in RDP or collect relative input in RDP. This makes sense because warping the mouse would require moving the client's cursor.

Relative mouse motion in RDP is unsupported according to Microsoft: https://social.msdn.microsoft.com/Forums/en-US/ae516842-1e3d-4943-8144-1b225e74684e/relativemousemode?forum=os_windowsprotocols

(In reply to superfury from comment # 78)

Also, according to the Microsoft documentation, just relying on said bit is wrong, as that can theoretically also include a mouse(when the value of the low byte is 0x80), as it states the low 7 bits being 0 for a mouse, besides failing on pre-Vista.

The idea that 0x80 would ever be set for a mouse on Vista+ does not seem consistent with the documentation, which states:

"Additionally, in Windows Vista, the eighth bit, masked by 0x80, is used to differentiate touch input from pen input (0 = pen, 1 = touch)."

I don't see how a mouse could ever be touch. But as I said above, I'm not opposed to changing the check to 0x7F. It's not important that we check all the bits in the extra data, just that we check the set that is necessary to identify touch events.

It's bug 4713 that's not working at all, and as far as it's working it's only on Vista and up.

What happened with the warp=1 case is fixed with the v3 addition(in my test code I added to my SDL2 program). It's just that Cameron hasn't replied yet if it's working in his case after I've posted the fix. It's running like a charm(not taking the different bug that has to do with mouse warping not working with RDP into account).

My v2 and v3 diffs combined fully fix the problem that this thread was about (seperating touch and mouse events properly during touch and mouse input through RDP). Mouse cursor warping not working is an entirely different issue, but I was just wondering if anyone knew something about it(not related to the input filters themselves).

v3 does not work for me. I still seeing spurious mouse motions when relative warp is enabled. I'm beginning to wonder if this spurious touch motion with relative warp is a Windows bug after all. That would certainly explain why it appears new to me. I don't remember seeing it before on 1809 with SDL 2.0.9. When I go back to 2.0.9 on 1903, I'm still seeing it. This matches with the downstream bug report I received last year which explicitly states that raw input disabled fixes the jumping: https://github.com/moonlight-stream/moonlight-qt/issues/140

On 2019-07-22 15:04:05 +0000, wrote:

I just checked the v3(with v2 already being on hg) using the latest(Windows 10 Pro 1903). Somehow the events (exactly one motion event per touch movement(stopping to move(when dragging) or touch release(when releasing), but not both at the same time) are popping up now. On 1803 that didn't happen at all(all touch events were properly filtered with v2+v3, half on v2, none on bug 4713), so that confirms the remaining motion going unfiltered with v3 is a Microsoft bug.

On 2019-07-22 15:26:19 +0000, wrote:

So the v2 and v3 patches are definitely required for SDL to properly detect all the cases.

It´s just that AFTER applying them, the condition on line 380 of SDL_windowsevents.c might need to be changed as you've said. All the other changes in v2 and v3 ARE required to make SDL properly handle all cases correctly(checking all incoming packets for all types(whether mouse etc.) and all the patches that don't directly have to do with the input filtering(the conditional setting of the variables in the mouse.h added variables for filtering the extra events that windows sends that need to be filtered and can't be filtered based on line 380 only(the stuff that happens in SDL_MOUSELEAVE and in GetMessageExtraInfoAndCheckMousePacketTouch lines 381-389 for ALL windows mouse-related handlers(where GetMessageExtraInfoAndCheckMousePacketTouch gets called)))).

The only thing left to do with this is to fix line 390 to maybe do as you've said (if that's indeed correct and as simple as it sounds)) with the &0x7F and perhaps OR(logical) that with the bit7(if that's indeed to be used) and/or the masked data in bits 8-31.

All other things are required to stay in there, as they are the main filtering method for all the other junk that Windows sends to the app that need discarding(the trailing wm_mouseleave event and the trailing 0x00000000 wm_mousemove event to be exact).

On 2019-07-22 16:01:30 +0000, wrote:

About this line: *checkTouch = (!(((extrainfo & 0x7F) && (isVistaOrNewer ? (extrainfo & 0x80) : 1)) || ((extrainfo & 0xFFFFFF00) == 0xFF515700)));

To apply your case with ONLY checking the 0x7F case, that would become(as you've said): *checkTouch = (!(extrainfo & 0x7F));

If the mask also would need to be checked against(as Microsoft documents), that would be (if I'm not mistaken): *checkTouch = (!((extrainfo & 0x7F) || ((extrainfo & 0xFFFFFF00) == 0xFF515700)));

The latter (with the ((extrainfo&mask)==ID) should be used I think, because the microsoft documentation clearly states:

"" If the comparison is true, then this mouse message was generated by a Tablet PC pen or touch screen. In all other cases, you can assume that this message was generated by a mouse device.

The lower 8 bits returned from GetMessageExtraInfo are variable. Of those bits, 7 (the lower 7, masked by 0x7F) are used to represent the cursor ID, zero for the mouse or a variable value for the pen ID. Additionally, in Windows Vista, the eighth bit, masked by 0x80, is used to differentiate touch input from pen input (0 = pen, 1 = touch). ""

So if I'm not mistaken, bits 0-7 is 0 for a mouse, otherwise, it is touch/pen(which should be filtered). Then it also states the comparison with the mask and ID identifies a touch/PC pen. So if that is set, but the lower 7 bits are 0, it's a touch/Pen anyways(it doesn't mention how the two are combined, but thinking logically, it's basically an OR-operation in that case, as either or both conditions can be true when looking at them seperately).

So, the correct would be the latter case?

On 2019-07-22 16:36:09 +0000, wrote:

Created attachment 3891 Improvements to the hg repository as a new v3 patch (after the v2 patch that's already in hg) with simplified checks.

I've adjusted the code based on Cameron's latest comments(concerning the checks on the GetMessageExtraInfo data). I've also removed the duplicate checks that were there(the MOUSEEVENTF_FROMTOUCH code locations) and moved them to the function that checks the trailing events directly, but as Microsoft has documented them(so not just invalidly checking parts and bits of the high 24 bits instead of the whole value that's at that location(as Microsoft CLEARLY states that all the 24 bits should be checked and not just part of those bits(as the bitmask that was used fully ignores some of the high bits incorrectly(bits 11, 13, 15, 17-19, 21 and 23(the bits that weren't set in the MOUSEEVENTF_FROMTOUCH constant))))).

Also, the same as for my previous diffs counts for the incorrect spaces turning into tabs(which needs conversion to spaces for actually committing).

On 2019-07-22 17:14:09 +0000, wrote:

Just looked at the results of the latest diff from my last post(which is basically the v3 patch on the hg repository, but with the event mask moved to the function which handles all general touch-related stuff(the retrieving and full checking of the GetMessageExtraInfo() function). The other places that handled them now use this function, so I just moved the check for the MOUSEEVENTF_FROMTOUCH there entirely and fixed it according to the Microsoft documentation and my interpretation of it(see my last commit).

I see that it continues to stream mouse movement packets to the application using RDP and touch input in relative mode only(it's logged in the format Mouse Motion: %i,%i=%i,%i where the four are event.motion.x, event.motion.y, event.motion.xrel, event.motion.yrel).

CRITICAL: Mouse motion: 0,0=0,0 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-69,-28 CRITICAL: Mouse motion: 0,0=-211,-125 CRITICAL: Mouse motion: 0,0=-211,-124 CRITICAL: Mouse motion: 0,0=-211,-124 CRITICAL: Mouse motion: 0,0=-211,-123 CRITICAL: Mouse motion: 0,0=-211,-123 CRITICAL: Mouse motion: 0,0=-211,-123 CRITICAL: Mouse motion: 0,0=-211,-122 CRITICAL: Mouse motion: 0,0=-211,-122 CRITICAL: Mouse motion: 0,0=-211,-122 CRITICAL: Mouse motion: 0,0=-211,-122 CRITICAL: Mouse motion: 0,0=-211,-122 CRITICAL: Mouse motion: 0,0=-211,-122 CRITICAL: Mouse motion: 0,0=-211,-122 CRITICAL: Mouse motion: 36,108=36,108 CRITICAL: Mouse motion: 73,217=37,109 CRITICAL: Mouse motion: 110,326=37,109 CRITICAL: Mouse motion: 147,435=37,109 CRITICAL: Mouse motion: 184,544=37,109 CRITICAL: Mouse motion: 221,599=37,109 CRITICAL: Mouse motion: 258,599=37,109 CRITICAL: Mouse motion: 295,599=37,109 CRITICAL: Mouse motion: 333,599=38,109 CRITICAL: Mouse motion: 372,599=39,109 CRITICAL: Mouse motion: 411,599=39,110 CRITICAL: Mouse motion: 450,599=39,110 CRITICAL: Mouse motion: 489,599=39,110 CRITICAL: Mouse motion: 528,599=39,110 CRITICAL: Mouse motion: 567,599=39,110 CRITICAL: Mouse motion: 606,599=39,110 CRITICAL: Mouse motion: 645,599=39,110 CRITICAL: Mouse motion: 684,599=39,110 CRITICAL: Mouse motion: 723,599=39,110 CRITICAL: Mouse motion: 762,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=39,110 CRITICAL: Mouse motion: 799,599=21,110 CRITICAL: Mouse motion: 711,599=-88,116 CRITICAL: Mouse motion: 576,599=-135,107 CRITICAL: Mouse motion: 306,599=-270,123 CRITICAL: Mouse motion: 35,599=-271,123 CRITICAL: Mouse motion: 0,599=-275,123 CRITICAL: Mouse motion: 0,599=-275,123 CRITICAL: Mouse motion: 0,599=-275,122 CRITICAL: Mouse motion: 0,599=-275,121 CRITICAL: Mouse motion: 0,599=-275,120 The thread 0x3ea0 has exited with code 0 (0x0). CRITICAL: Mouse motion: 0,599=-275,120 CRITICAL: Mouse motion: 0,599=-275,119 CRITICAL: Mouse motion: 0,599=-275,118 CRITICAL: Mouse motion: 0,599=-275,118 CRITICAL: Mouse motion: 0,599=-275,118 CRITICAL: Mouse motion: 0,599=-275,117 CRITICAL: Mouse motion: 0,599=-275,117 CRITICAL: Mouse motion: 0,599=-275,117 CRITICAL: Mouse motion: 0,599=-275,117 CRITICAL: Mouse motion: 0,599=-275,116 CRITICAL: Mouse motion: 0,599=-275,116 CRITICAL: Mouse motion: 0,599=-275,116 CRITICAL: Mouse motion: 0,599=-275,116 CRITICAL: Mouse motion: 0,599=-275,116 CRITICAL: Mouse motion: 0,599=-275,116 CRITICAL: Mouse motion: 0,599=-275,116 CRITICAL: Mouse motion: 0,599=-274,116 CRITICAL: Mouse motion: 0,599=-274,116 CRITICAL: Mouse motion: 0,599=-274,116 CRITICAL: Mouse motion: 0,599=-273,116 CRITICAL: Mouse motion: 0,599=-273,116 CRITICAL: Mouse motion: 0,599=-272,116 CRITICAL: Mouse motion: 0,599=-271,115 CRITICAL: Mouse motion: 0,599=-270,114 CRITICAL: Mouse motion: 0,599=-270,112 CRITICAL: Mouse motion: 0,599=-270,112 CRITICAL: Mouse motion: 0,599=-270,112 CRITICAL: Mouse motion: 0,599=-270,112 CRITICAL: Mouse motion: 0,599=-269,112 CRITICAL: Mouse motion: 0,599=-269,112 CRITICAL: Mouse motion: 0,599=-267,111 CRITICAL: Mouse motion: 0,599=-264,111 CRITICAL: Mouse motion: 0,599=-222,100 CRITICAL: Mouse motion: 0,599=-159,45 CRITICAL: Mouse motion: 213,350=213,-249 CRITICAL: Mouse motion: 424,104=211,-246 CRITICAL: Mouse motion: 634,0=210,-240 CRITICAL: Mouse motion: 799,0=209,-240 CRITICAL: Mouse motion: 799,0=208,-238 CRITICAL: Mouse motion: 799,0=207,-238 CRITICAL: Mouse motion: 799,0=205,-235 CRITICAL: Mouse motion: 799,0=204,-233 CRITICAL: Mouse motion: 799,0=204,-232 CRITICAL: Mouse motion: 799,0=203,-228 CRITICAL: Mouse motion: 799,0=203,-226 CRITICAL: Mouse motion: 799,0=201,-226 CRITICAL: Mouse motion: 799,0=201,-224 CRITICAL: Mouse motion: 799,0=200,-224 CRITICAL: Mouse motion: 799,0=199,-224 CRITICAL: Mouse motion: 799,0=199,-224 CRITICAL: Mouse motion: 799,0=198,-224 CRITICAL: Mouse motion: 799,0=197,-224 CRITICAL: Mouse motion: 799,0=197,-224 CRITICAL: Mouse motion: 799,0=196,-224 CRITICAL: Mouse motion: 799,0=196,-224 CRITICAL: Mouse motion: 799,0=196,-224 CRITICAL: Mouse motion: 799,0=196,-224 CRITICAL: Mouse motion: 799,0=196,-224 CRITICAL: Mouse motion: 799,0=195,-224 CRITICAL: Mouse motion: 799,0=195,-224 CRITICAL: Mouse motion: 799,0=195,-224 CRITICAL: Mouse motion: 799,0=195,-224 CRITICAL: Mouse motion: 799,0=194,-224 CRITICAL: Mouse motion: 799,0=194,-224 CRITICAL: Mouse motion: 799,0=194,-224 CRITICAL: Mouse motion: 799,0=194,-224 CRITICAL: Mouse motion: 799,0=194,-224 CRITICAL: Mouse motion: 799,0=192,-224 CRITICAL: Mouse motion: 799,0=192,-224 CRITICAL: Mouse motion: 799,0=190,-223 CRITICAL: Mouse motion: 799,0=189,-223 CRITICAL: Mouse motion: 799,0=188,-223 CRITICAL: Mouse motion: 634,0=-165,-217 CRITICAL: Mouse motion: 468,0=-166,-217 CRITICAL: Mouse motion: 302,0=-166,-217 CRITICAL: Mouse motion: 136,0=-166,-217 CRITICAL: Mouse motion: 0,0=-166,-217 CRITICAL: Mouse motion: 0,0=-166,-217 CRITICAL: Mouse motion: 0,0=-167,-217 CRITICAL: Mouse motion: 0,0=-168,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-217 CRITICAL: Mouse motion: 0,0=-169,-216 CRITICAL: Mouse motion: 0,0=-169,-216 CRITICAL: Mouse motion: 0,0=-169,-216 CRITICAL: Mouse motion: 0,0=-169,-216 CRITICAL: Mouse motion: 0,0=-169,-216 CRITICAL: Mouse motion: 0,0=-169,-215 CRITICAL: Mouse motion: 0,0=-169,-215 CRITICAL: Mouse motion: 0,0=-169,-215 CRITICAL: Mouse motion: 0,0=-169,-215 CRITICAL: Mouse motion: 0,0=-169,-216 CRITICAL: Mouse motion: 399,0=399,-300

The first three touches can be ignored(that's me toggling to relative mode in my touch-based application). So starting from the final "799,599" line, that's me testing the input functionality. I placed my finger on the screen, dragging it to the right from there. Then dragged it to the left and bottom left, then dragged it to the top-right.

As can be seen, apparently the absolute locations(x and y variables) become some kind of marker where it was pressed. Then the xrel and yrel motions become the finger's relative location compared to the point the finger started touching the screen. So when I press the center of a 800x600 window, it's reported as windowwidth,windowheight. Then, dragging it left/right/up/down changes only the xrel and yrel coordinates to the location on the screen the touch is at compared to that reference position?

I did see one big hint as to what the problem might be:

Somehow, the reference position(.x and .y of the event.motion) becomes 0 when dragging before the x or y location(when finger x/y coordinate<start x/y coordinate) and windowxsize-1 or windowysize-1 otherwise. The xrel and yrel values are always the position of the touch compared to the location the touch started being pressed! Perhaps this is a hint in the SDL system that identifies why these events are happening? Is there some system inside the SDL event handling that has this behaviour? Or is this purely the cause of the absolute nature of the touch/mouse events from RDP?

On 2019-07-22 18:14:59 +0000, wrote:

Hmmm... Weird. Reversed Windows to 1803, after which RDP caused an unresponsive black screen!

On 2019-07-22 18:32:04 +0000, wrote:

After a quick hard reboot(using the reset button on the desktop front) RDP works correctly again(it somehow disconnected in the middle of connecting).

Well, the results are interesting! With build 1803 I'm on right now, some normal mouse motion comes in normally when not yet in relative mode: CRITICAL: Mouse motion: 392,159=-8,70 The thread 0x340c has exited with code 0 (0x0). CRITICAL: Mouse motion: 379,244=-13,85 CRITICAL: Mouse motion: 365,331=-14,87 CRITICAL: Mouse motion: 341,486=-24,155 CRITICAL: Mouse motion: 324,478=-17,-8 CRITICAL: Mouse motion: 315,415=-9,-63 CRITICAL: Mouse motion: 306,355=-9,-60 CRITICAL: Mouse motion: 183,304=-123,-51 CRITICAL: Mouse motion: 68,253=-115,-51 CRITICAL: Mouse motion: 0,202=-112,-51 CRITICAL: Mouse motion: 43,153=43,-49 CRITICAL: Mouse motion: 85,105=42,-48 CRITICAL: Mouse motion: 85,0=0,-211

But, when the relative mode is once again enabled after that(using touch only), nothing more is dumped in the application output. So the SDL2 filter is working properly on build 1803. That is of course the last change I made(with the diff from comment 91 still being used).

So, the problem that the filter is failing is purely due to the build differences between 1903 and 1803! That's hereby confirmed!

On 2019-07-22 23:53:26 +0000, Sam Lantinga wrote:

I'm moving the rest of the bugfix post 2.0.10.

I'm very confused as to what the bug still is, what happens on various versions of Windows, and what the correct fix is.

Can someone, in a single comment, very simply describe what the current behavior is on each version of Windows, (disregarding mouse warping on RDP, which doesn't work) and whether the attached final patch fixes them?

Thanks!

On 2019-07-23 01:13:33 +0000, Cameron Gutman wrote:

The bug is that SDL generates spurious SDL_MouseMotionEvents with which=0 instead of SDL_TOUCH_MOUSEID when the user taps the touchscreen in certain cases. This causes unwanted motion in the app due to the app receiving both synthetic mouse motion events marked as real ones and real touch events. The synthetic mouse events also often appear to be disproportionate to the actual touch motion. See https://bugzilla.libsdl.org/show_bug.cgi?id=4704#c56 for an event trace demonstrating the bug with SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1.

The tested behavior is as follows:

With SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1

  • Windows 10 1903/19H1 - Affected on SDL 2.0.9 and Hg (tested by me and superfury)
  • Windows 10 1809 - Not affected on SDL 2.0.9 and Hg (tested by me)
  • Windows 10 1803 - Not affected on SDL 2.0.9 and Hg (tested by superfury)

With SDL_HINT_MOUSE_RELATIVE_MODE_WARP=0 (default)

I don't know how many users depend on Windows touch support with SDL_HINT_MOUSE_RELATIVE_MODE_WARP=1 set, but since this is the only report and the bug is already in the wild would guess it's not many people. It appears to be something in Windows 10 1903 that caused it. It also remains to be seen whether Windows 10 19H2 or 20H1 will fix it or if it's expected to be the behavior from Windows going forward.

I think it makes sense to wait and see and ship 2.0.10 with only the fixes for SDL_HINT_MOUSE_RELATIVE_MODE_WARP=0.

On 2019-07-30 17:49:37 +0000, Ryan C. Gordon wrote:

(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.

On 2019-08-30 22:33:27 +0000, Sam Lantinga wrote:

FYI, I changed the code to allow mouse events from pen clicks, which may affec this bug: https://hg.libsdl.org/SDL/rev/8254c364ec4a

On 2019-09-01 10:39:54 +0000, wrote:

Won't it cause issues ignoring bits 0-6 in your commit? Microsoft clearly says it's a mouse when they're zeroed (even if the signature is set). You're currently detecting the mouse as touch/pen in that case.

Also, you're checking bit 7(0x80) even on XP systems, which have total garbage or undefined behaviour in said bit(Microsoft DOES say that it's only valid on Vista and up, which is why the Vista check was there(just assuming it's 1 on every XP version is blatantly ignoring Microsoft specs). In that case it will misdetect those cases.

On 2019-09-20 20:47:36 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks, --ryan.

On 2019-09-20 20:48:43 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks, --ryan.

On 2020-04-21 11:38:11 +0000, wrote:

I've just been reading some things...

It looks like the Microsoft Remote Desktop I'm using actually converts touch input(from Android) to pen inputs.

Then, the current code in the SDL 2.0.12 release doesn't filter the 'pen' inputs at all, causing the pen inputs to get through to both touch and mouse events, causing my app to handle the touch inputs both as mouse movement, mouse clicks, touch taps and touch movements, instead of just touch movement and tap.

So the obvious solution would be to add another kind of information to mouse events to identify pen input? Or simply disable the pen input when Remote Desktop is used and just use the current touch events(touch handling unmodified, while mouse events of pen is ignored during RDP) instead?

https://www.windowscentral.com/microsoft-improves-working-pen-windows-10s-remote-desktop

Or perhaps allow the mouse events to have something to identify the pen input being used for compatiblity with apps not supporting it directly?

On 2020-04-21 12:56:51 +0000, wrote:

Just tried the current SDL hg commit.

I still see events getting through from SDL_windowsevents.c line 631 only. Stuff like mouse press/release/motion events when performing touches on RDP(with RDP setup for touch instead of mouse input).

So apparently the filter isn't working correctly, or that function call at said line is misbehaving?

On 2020-04-21 13:28:53 +0000, wrote:

Just found something out: Windows 10 seems to be lying about input.

I see values of C7/C8/F7/F8/F9 in the GetMessageExtraInfo result when using RDP in touch input mode, tapping and dragging accross the screen.

I never even once see it actively setting the signature anymore. Either Windows 10 has a huge bug there, not reporting the signatures at all anymore, or SDL2 is now assuming the signature will be set, while it isn't anymore for current (and/or future) Windows 10 builds.

On 2020-04-21 14:02:03 +0000, wrote:

The following change in code seems to fix the touch events input to be detected correctly again: static SDL_MOUSE_EVENT_SOURCE GetMouseMessageSource() { LPARAM extrainfo = GetMessageExtraInfo(); / Mouse data (ignoring synthetic mouse events generated for touchscreens) / / Versions below Vista will set the low 7 bits to the Mouse ID and don't use bit 7: Check bits 8-32 for the signature (which will indicate a Tablet PC Pen or Touch Device). Only check bit 7 when Vista and up(Cleared=Pen, Set=Touch(which we need to filter out)), when the signature is set. The Mouse ID will be zero for an actual mouse. / //When the lower 8 bits of extrainfo isn't zero while the upper bits of extrainfo is zero, Windows is lying to us: it's actually a pen/touch event(missing signature)! if (IsTouchEvent(extrainfo) || ((extrainfo&0xFF) && ((extrainfo&~0xFF)==0))) { if (extrainfo & 0x80) { return SDL_MOUSE_EVENT_SOURCE_TOUCH; } else { return SDL_MOUSE_EVENT_SOURCE_PEN; } } return SDL_MOUSE_EVENT_SOURCE_MOUSE; }

So simply said: it looks like Windows 10 won't properly generate the signature anymore, leaving it 0 while actually filling the lower bits correctly(with 0x1-0x7, 0xC and 0xF values).

slouken commented 11 months ago

SDL 2.0 is now in maintenance mode, and all inactive issues are being closed. If this issue is impacting you, please feel free to reopen it with additional information.