No keyboard input after enable "Emulate 3 button mouse" #85562

New Issue

Valentin · 2021-02-12T00:25:42+01:00

Valentin commented

2021-02-12 00:25:42 +01:00

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

Blender Version
Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-02-11 17:37, hash: a608313860
Worked: (newest version of Blender that worked as expected)

Short description of error
No keyboard input after enable "Emulate 3 button mouse"

Exact steps for others to reproduce the error

Default blender cube
In preference->input->mouse, check or uncheck "emulate 3 Button Mouse"
blender does not respond to keyboard input, you're unable to pan the view nor write in fields nor anything

git bisect narrow down to: 1c4ae8a11c

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 452.41 **Blender Version** Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-02-11 17:37, hash: `a608313860` Worked: (newest version of Blender that worked as expected) **Short description of error** No keyboard input after enable "Emulate 3 button mouse" **Exact steps for others to reproduce the error** * Default blender cube * In preference->input->mouse, check or uncheck "emulate 3 Button Mouse" * blender does not respond to keyboard input, you're unable to pan the view nor write in fields nor anything **git bisect narrow down to:** 1c4ae8a11c820e33da7

Valentin commented

2021-02-12 00:25:42 +01:00

Added subscriber: @Poulpator

Valentin commented

2021-02-12 00:28:00 +01:00

Added subscribers: @Harley, @brecht

Valentin commented

2021-02-12 00:28:00 +01:00

poke @Harley @brecht since you were involved in 1c4ae8a11c

poke @Harley @brecht since you were involved in 1c4ae8a11c820e33da7

TheRedWaxPolice commented

2021-02-12 03:59:53 +01:00

Added subscriber: @TheRedWaxPolice

TheRedWaxPolice commented

2021-02-12 03:59:53 +01:00

Hmm yeah... in my case, even without enabling "emulate 3 Button Mouse", Blender stops responding to keyboard input as soon as I open a new window, like preferences/render etc...

Jason Clarke commented

2021-02-12 04:09:11 +01:00

Added subscriber: @JasonClarke

Jason Clarke commented

2021-02-12 04:09:59 +01:00

I'm noticing the same thing, 2.93 doesn't respond to keyboard input after a new window has been opened.

Wannes Malfait commented

2021-02-12 08:55:16 +01:00

Added subscriber: @wannes.malfait

Wannes Malfait commented

2021-02-12 08:55:16 +01:00

Yes I can confirm as well. The moment I open up another window (in blender like preferences) no keyboard input is detected, even after closing it. Keyboard input is detected in the preferences window though.

Harley Acheson self-assigned this 2021-02-12 16:27:25 +01:00

Harley Acheson commented

2021-02-12 16:27:25 +01:00

Will probably just confirm and revert (all or part of) that commit very soon - just woke up. I’m guessing this affects Windows only and is fixed with one line (forcing is_dialog always true). I had been trying to understand a different bad result but so far it had not made sense. This report might help me with that but I don’t want to leave master in this state now that I see the failure is more profound.

Harley Acheson commented

2021-02-12 18:52:45 +01:00

Added subscriber: @PrototypeNM1

Harley Acheson commented

2021-02-12 18:52:45 +01:00

This appears to be related to a particular section of code run during W32 Window creation. In file GHOST_WindowWin32.cpp, in GHOST_WindowWin32(), at about line 223 there is a section of code:

  if (parentwindow && !dialog) {
    RAWINPUTDEVICE device = {0};
    device.usUsagePage = 0x01; /* usUsagePage & usUsage for keyboard*/
    device.usUsage = 0x06;     /* http://msdn.microsoft.com/en-us/windows/hardware/gg487473.aspx */
    device.dwFlags |=
        RIDEV_INPUTSINK;  // makes WM_INPUT is visible for ghost when has parent window
    device.hwndTarget = m_hWnd;
    RegisterRawInputDevices(&device, 1, sizeof(device));
  }

If that is NOT run, then everything seems to be right with the world. But I'm not (yet) certain of the intention of that code., whether the circumstances have changed, or if it addressed a old issue that was fixed in later OS versions, etc. So I don't know if there are bad effects if it is omitted, even though I have found none so far.

@PrototypeNM1 - can you guess what this code is doing or is supposed to do?

This appears to be related to a particular section of code run during W32 Window creation. In file GHOST_WindowWin32.cpp, in GHOST_WindowWin32(), at about line 223 there is a section of code: ``` if (parentwindow && !dialog) { RAWINPUTDEVICE device = {0}; device.usUsagePage = 0x01; /* usUsagePage & usUsage for keyboard*/ device.usUsage = 0x06; /* http://msdn.microsoft.com/en-us/windows/hardware/gg487473.aspx */ device.dwFlags |= RIDEV_INPUTSINK; // makes WM_INPUT is visible for ghost when has parent window device.hwndTarget = m_hWnd; RegisterRawInputDevices(&device, 1, sizeof(device)); } ``` If that is NOT run, then everything seems to be right with the world. But I'm not (yet) certain of the intention of that code., whether the circumstances have changed, or if it addressed a old issue that was fixed in later OS versions, etc. So I don't know if there are bad effects if it is omitted, even though I have found none so far. @PrototypeNM1 - can you guess what this code is doing or is supposed to do?

Brecht Van Lommel commented

2021-02-12 18:59:43 +01:00

It's from 0b03268.

Just remove it if that solves the issue. The RIM_INPUTSINK change from the same commit should also be removed I think.

It's from 0b03268. Just remove it if that solves the issue. The `RIM_INPUTSINK` change from the same commit should also be removed I think.

Harley Acheson commented

2021-02-12 19:09:37 +01:00

@brecht - yes. Looking through this, the best way to explain is...

Our problem in getting our windows "on top" in Win32 is because we were only passing the parent handle if "dialog" was true. So there were only two combinations before: (dialog and parentwindow), and (!notdialog and null). So I think that code was never run ever before. Or, more likely, it was added at the the time that "dialog" was added it then became unreachable.

@brecht - yes. Looking through this, the best way to explain is... Our problem in getting our windows "on top" in Win32 is because we were only passing the parent handle if "dialog" was true. So there were only **two** combinations before: (dialog and parentwindow), and (!notdialog and null). So I think that code was never run ever before. Or, more likely, it was added at the the time that "dialog" was added it then became unreachable.

Harley Acheson commented

2021-02-12 19:11:21 +01:00

yes, exactly that when looking at that patch from 2011

blender-admin commented

2021-02-12 19:39:33 +01:00

This issue was referenced by ba03f7f0b1

This issue was referenced by ba03f7f0b1d0c40acf997749949a0b0efe19e6d0

Harley Acheson commented

2021-02-12 19:40:40 +01:00

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

Harley Acheson closed this issue

2021-02-12 19:40:40 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

No keyboard input after enable "Emulate 3 button mouse" #85562