Walk navigation stylus issues in 2.92 - no mouse input until alt tabbing (regression) #84659

New Issue

Vas · 2021-01-13T01:18:23+01:00

Vas commented

2021-01-13 01:18:23 +01:00

System Information
Operating system: Windows-10-10.0.17763-SP0 64 Bits
Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30

Blender Version
Broken: version: 2.92.0 Alpha, branch: master, commit date: 2021-01-11 21:30, hash: acbda123ad
Worked: version: version: 2.91.0, branch: master, commit date: 2020-11-25 08:34, hash: 0f45cab862 *

Short description of error
Walk mode seems to be a bit broken in 2.92 alpha (with both mouse and wacom tablet)

The issue only happens if Walk mode is entered via keyboard shortcut
alt tabbing out and back into the blender seems to fix the mouse lock

*Important note:
I noticed that this issue is a bit less severe in an older 2.92 build !!2.92.0 Alpha, branch: master, commit date: 2020-12-29 18:57, hash: c1740e9ad0!!, there was still an issue where wacom stylus had to be lifted from tablet surface and placed down again in order for blender to start registering mouse movement in walk mode. (The mouse worked fine, this is pen tablet only issue)

Here's a short video demonstrating issue

Example 1: Blender 2.91 hash: 0f45cab862 - Works as intended
Example 2: Blender 2.92 hash: c1740e9ad0 - Works BUT only if stylus is lifted from screen (note stylus diagnostic screen on right side)
Example 3: Blender 2.92 hash: acbda123ad - Only works if user alt tabs from the window itself
2021-01-13 00-09-24.mp4

Exact steps for others to reproduce the error

Default document
3D Viewport > View > Navigation > Walk Navigation - Assign a keyboard shortcut (eg: Shift + F)
Press the previously defined shortcut
Walk mode crosshair appears but mouse is locked
Alt tab out and back into blender
Now walk mode works

**System Information** Operating system: Windows-10-10.0.17763-SP0 64 Bits Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30 **Blender Version** Broken: version: 2.92.0 Alpha, branch: master, commit date: 2021-01-11 21:30, hash: `acbda123ad` Worked: version: version: 2.91.0, branch: master, commit date: 2020-11-25 08:34, hash: `0f45cab862` * **Short description of error** Walk mode seems to be a bit broken in 2.92 alpha (with both mouse and wacom tablet) - The issue only happens if Walk mode is entered via keyboard shortcut - alt tabbing out and back into the blender seems to fix the mouse lock *Important note: I noticed that this issue is a bit less severe in an older 2.92 build !!2.92.0 Alpha, branch: master, commit date: 2020-12-29 18:57, hash: `c1740e9ad0`!!, there was still an issue where wacom stylus had to be lifted from tablet surface and placed down again in order for blender to start registering mouse movement in walk mode. (The mouse worked fine, this is pen tablet only issue) **Here's a short video demonstrating issue** - Example 1: Blender 2.91 hash: `0f45cab862` - Works as intended - Example 2: Blender 2.92 hash: `c1740e9ad0` - Works BUT only if stylus is lifted from screen (note stylus diagnostic screen on right side) - Example 3: Blender 2.92 hash: `acbda123ad` - Only works if user alt tabs from the window itself [2021-01-13 00-09-24.mp4](https://archive.blender.org/developer/F9561675/2021-01-13_00-09-24.mp4) **Exact steps for others to reproduce the error** - Default document - 3D Viewport > View > Navigation > Walk Navigation - Assign a keyboard shortcut (eg: Shift + F) - Press the previously defined shortcut - Walk mode crosshair appears but mouse is locked - Alt tab out and back into blender - Now walk mode works

Vas commented

2021-01-13 01:18:23 +01:00

Added subscriber: @Alumx

blender-admin commented

2021-01-13 01:18:23 +01:00

#84166 was marked as duplicate of this issue

Robert Guetzkow commented

2021-01-13 09:56:38 +01:00

Added subscribers: @PrototypeNM1, @rjg

Robert Guetzkow commented

2021-01-13 09:56:38 +01:00

@PrototypeNM1 This is likely for you.

Nicholas Rishel self-assigned this 2021-01-13 20:00:03 +01:00

Nicholas Rishel commented

2021-01-13 23:18:20 +01:00

Added subscriber: @VincentBlankfield

Nicholas Rishel commented

2021-01-13 23:18:20 +01:00

@VincentBlankfield could you take a look at this? You're more familiar with tablet-walk mode interaction.

Vincent Blankfield commented

2021-01-15 21:34:21 +01:00

Isn't this the same issue as #84166?

@PrototypeNM1 I'm afraid I'm not familiar neither with the walk operator nor the event system. Most that I can do here is to point at some places in the code, leaving the actual fixing to someone who has a clue.

What I've found out is that walkEvent() in view3d_walk.c seems to expect receiving an event with mouse coordinates set exactly to what have been previously passed to WM_cursor_warp(). It will be stuck waiting until such event is received:

    if (walk->is_cursor_first) {
      /* wait until we get the 'warp' event */
      if ((walk->center_mval[0] == event->mval[0]) && (walk->center_mval[1] == event->mval[1])) {
        walk->is_cursor_first = false;
      }
      else {
        /* note, its possible the system isn't giving us the warp event
         * ideally we shouldn't have to worry about this, see: T45361 */
        wmWindow *win = CTX_wm_window(C);
        WM_cursor_warp(win,
                       walk->region->winrct.xmin + walk->center_mval[0],
                       walk->region->winrct.ymin + walk->center_mval[1]);
      }
      return;
    }

I'm not completely sure about the reason behind that, but my guess would be that there may be some other events in between. So if is_cursor_first is set right away, the cursor centering event (probably sent by other systems) may jerk the view when it arrives. The problem here is that the new GHOST_SystemWin32 doesn't send any event on setCursorPosition. Anyway, setting walk->is_cursor_first = false in the else block makes the issue go away, but is most likely wrong.

Another approach would be to send a cursor event on setCursorPosition (WM_cursor_warp). My guess is that all GHOST event systems are supposed to do it for consistency:

diff --git a/intern/ghost/intern/GHOST_SystemWin32.cpp b/intern/ghost/intern/GHOST_SystemWin32.cpp
index 718ace9db4a..37a66ea1255 100644
--- a/intern/ghost/intern/GHOST_SystemWin32.cpp
+++ b/intern/ghost/intern/GHOST_SystemWin32.cpp
@@ -549,6 +549,19 @@ GHOST_TSuccess GHOST_SystemWin32::setCursorPosition(GHOST_TInt32 x, GHOST_TInt32
   input.mi.dwFlags = MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_VIRTUALDESK;
   SendInput(1, &input, sizeof(input));

+  // Not Sure if I'm doing this the right way.
+  GHOST_SystemWin32 *system = (GHOST_SystemWin32 *)getSystem();
+  GHOST_IWindow *window = system->getWindowManager()->getActiveWindow();
+  system->pushEvent(new GHOST_EventCursor(::GetMessageTime(),
+                                          GHOST_kEventCursorMove,
+                                          window,
+                                          x,
+                                          y,
+                                          GHOST_TABLET_DATA_NONE));
+
   return GHOST_kSuccess;
 }

Isn't this the same issue as #84166? @PrototypeNM1 I'm afraid I'm not familiar neither with the walk operator nor the event system. Most that I can do here is to point at some places in the code, leaving the actual fixing to someone who has a clue. What I've found out is that `walkEvent()` in `view3d_walk.c` seems to expect receiving an event with mouse coordinates set exactly to what have been previously passed to `WM_cursor_warp()`. It will be stuck waiting until such event is received: ``` if (walk->is_cursor_first) { /* wait until we get the 'warp' event */ if ((walk->center_mval[0] == event->mval[0]) && (walk->center_mval[1] == event->mval[1])) { walk->is_cursor_first = false; } else { /* note, its possible the system isn't giving us the warp event * ideally we shouldn't have to worry about this, see: T45361 */ wmWindow *win = CTX_wm_window(C); WM_cursor_warp(win, walk->region->winrct.xmin + walk->center_mval[0], walk->region->winrct.ymin + walk->center_mval[1]); } return; } ``` I'm not completely sure about the reason behind that, but my guess would be that there may be some other events in between. So if `is_cursor_first` is set right away, the cursor centering event (probably sent by other systems) may jerk the view when it arrives. The problem here is that the new `GHOST_SystemWin32` doesn't send any event on `setCursorPosition`. Anyway, setting `walk->is_cursor_first = false` in the `else` block makes the issue go away, but is most likely wrong. Another approach would be to send a cursor event on `setCursorPosition` (`WM_cursor_warp`). My guess is that all GHOST event systems are supposed to do it for consistency: ``` diff --git a/intern/ghost/intern/GHOST_SystemWin32.cpp b/intern/ghost/intern/GHOST_SystemWin32.cpp index 718ace9db4a..37a66ea1255 100644 --- a/intern/ghost/intern/GHOST_SystemWin32.cpp +++ b/intern/ghost/intern/GHOST_SystemWin32.cpp @@ -549,6 +549,19 @@ GHOST_TSuccess GHOST_SystemWin32::setCursorPosition(GHOST_TInt32 x, GHOST_TInt32 input.mi.dwFlags = MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_VIRTUALDESK; SendInput(1, &input, sizeof(input)); + // Not Sure if I'm doing this the right way. + GHOST_SystemWin32 *system = (GHOST_SystemWin32 *)getSystem(); + GHOST_IWindow *window = system->getWindowManager()->getActiveWindow(); + system->pushEvent(new GHOST_EventCursor(::GetMessageTime(), + GHOST_kEventCursorMove, + window, + x, + y, + GHOST_TABLET_DATA_NONE)); + return GHOST_kSuccess; } ```

Nicholas Rishel commented

2021-01-17 00:09:16 +01:00

Added subscriber: @ideasman42

Nicholas Rishel commented

2021-01-17 00:09:16 +01:00

@ideasman42 5e1a8055f4 is an old change but maybe you'd have an intuition for what fix is appropriate?

@ideasman42 5e1a8055f4 is an old change but maybe you'd have an intuition for what fix is appropriate?

Dalai Felinto commented

2021-02-15 11:17:07 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2021-02-15 11:17:07 +01:00

Navigation is such a core part of Blender that a regression that should be a high priority.

Philipp Oeser commented

2021-02-15 14:13:20 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-02-15 14:13:20 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2021-02-15 14:13:20 +01:00

Guess this should be confirmed

Nicholas Rishel commented

2021-02-16 17:00:22 +01:00

Added subscriber: @Vyach

Nicholas Rishel commented

2021-02-17 06:11:15 +01:00

Mouse hanging issues should be resolved by ab21009842. The Win32 SendInput API worked in coordinates [0, 65535] instead of pixel coordinates for absolute mouse moves, thus rounding errors could result in off by one errors in mouse position. This was an issue for the walk operator which waited for input to be exactly the center of the region.

Fix for tablets forthcoming.

Mouse hanging issues should be resolved by ab21009842. The Win32 SendInput API worked in coordinates [0, 65535] instead of pixel coordinates for absolute mouse moves, thus rounding errors could result in off by one errors in mouse position. This was an issue for the walk operator which waited for input to be exactly the center of the region. Fix for tablets forthcoming.

Vas commented

2021-02-18 17:19:02 +01:00

Hey sweet! the fly mode works now!

I think i found a new issue though, seems like sometimes mouse bugs out when shortcut is pressed quickly. Doing so whips camera around violently for some reason

(should I make a new task for this? @PrototypeNM1 )
2021-02-18 16-09-31.mp4

Hey sweet! the fly mode works now! I think i found a new issue though, seems like sometimes mouse bugs out when shortcut is pressed quickly. Doing so whips camera around violently for some reason (should I make a new task for this? @PrototypeNM1 ) [2021-02-18 16-09-31.mp4](https://archive.blender.org/developer/F9814997/2021-02-18_16-09-31.mp4)

Vincent Blankfield commented

2021-02-18 18:15:31 +01:00

It may be the effect I was talking about when saying:

So if is_cursor_first is set right away, the cursor centering event (probably sent by other systems) may jerk the view when it arrives.

Or there may be some unprocessed events before the actual mouse warp.

In any case, sending the a mousemove event after moving the cursor in setCursorPosition (WM_cursor_warp) will make sure all the unprocessed events before the mouse centering get ignored. There will be no need of the special case, that sets is_cursor_first = false right away for tablets.

Sorry, can't provide a code example as I currently don't have access to the source code. But general idea stays the same as in my previous comment. Also I'm not a developer, so may be wrong.

It may be the effect I was talking about when saying: > So if `is_cursor_first` is set right away, the cursor centering event (probably sent by other systems) may jerk the view when it arrives. Or there may be some unprocessed events before the actual mouse warp. In any case, sending the a mousemove event after moving the cursor in `setCursorPosition` (`WM_cursor_warp`) will make sure all the unprocessed events before the mouse centering get ignored. There will be no need of the special case, that sets `is_cursor_first = false` right away for tablets. Sorry, can't provide a code example as I currently don't have access to the source code. But general idea stays the same as in my previous comment. Also I'm not a developer, so may be wrong.

Nicholas Rishel commented

2021-02-18 19:26:00 +01:00

@Alumx the proposed change hasn't landed (unless someone sneaky committed it) so no need for an new issue.

@VincentBlankfield you're right, the issue is that when walk is started by a keyboard shortcut the operator doesn't know the current device is a tablet, so it tries to center the cursor, which does recenter on Windows Wintab because tablet input is just bolted onto mouse input (Windows Ink suppresses mouse input while active).

I'm not sure how Linux and Mac handle mouse/tablet interaction, anyone we can ping to check?

@Alumx the proposed change hasn't landed (unless someone sneaky committed it) so no need for an new issue. @VincentBlankfield you're right, the issue is that when walk is started by a keyboard shortcut the operator doesn't know the current device is a tablet, so it tries to center the cursor, which does recenter on Windows Wintab because tablet input is just bolted onto mouse input (Windows Ink suppresses mouse input while active). I'm not sure how Linux and Mac handle mouse/tablet interaction, anyone we can ping to check?

Nicholas Rishel commented

2021-02-23 06:27:42 +01:00

@Alumx I think everything is back to prior behavior in this build, could you verify so I can lower this task's priority? I believe the remaining issues are not regressions.

Edit: actually, could you go ahead and create another issue and tag me? The original report has higher severity than the current state of things, which is creating some confusion on what needs to be triaged. Sorry for changing instructions. <_<;;;

@Alumx I think everything is back to prior behavior in [this build](https://blender.community/c/graphicall/lsbbbc/), could you verify so I can lower this task's priority? I believe the remaining issues are not regressions. Edit: actually, could you go ahead and create another issue and tag me? The original report has higher severity than the current state of things, which is creating some confusion on what needs to be triaged. Sorry for changing instructions. <_<;;;

Nicholas Rishel commented

2021-02-23 21:24:38 +01:00

@dfelinto I think the remaining issues existed in 2.91 and relate to Windows Ink handling, and should really be a new task (my fault for discouraging such when asked). As the remaining issues don't seem to be regressions I'm going to bump the priority down and suggest we don't consider this a blocker for 2.92.

Stanislav Ovcharov commented

2021-07-21 21:24:42 +02:00

Added subscriber: @StanislavOvcharov

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Walk navigation stylus issues in 2.92 - no mouse input until alt tabbing (regression) #84659