Input system wouldn't process input events when unity in running without focus

[flame99999]

I'm using InputSystem.QueueStateEvent to feed input event into Unity. The events are being processed normally when unity is running with current focus, but totally ignored when unity is running in the background. Also, I have checked "run in background" in the player settings.

[flame99999]

Update: After upgrading to input system 0.2.10, queued stateEvetn can be processed in background with the built player, but still ignored in Editor when running in background.

[JiaUnity]

@flame99999 this sounds like by design.
The "Run in Background" setting is for target Player build only. It doesn't apply to the Editor.
In Editor, not running in the background is a intended design. It is consistent with the old input handling. The reason for that is in Editor, the user can make changes in the Scene window while in Playmode. If the input in the Scene window, like mouse movement, is passed over into Game window, it would interrupt the Editing process.
The common example for this is when mouse movement controls the camera angle. The user want to see how a certain change affects a Gameobject in real time. The user lines up the camera in the Game window, switch focus to the Scene window and start to move things around. As you can imagine, the mouse has been moving around quite a bit, and the view in the Game window has changed.
Not a bug.

[DrummerB]

@JiaUnity This behavior is not consistent with other implementations in the case of VR controllers. For instance, using the SteamVR Plugin or the old Input system (TrackedDevicePose), the controllers are tracked and report input even if the Game view is not in focus.
This makes sense since the VR controllers are not going to interfere with Editor controls. It also allows someone to playtest in VR, while someone else is tweaking the scene or doing other things on the desktop. With the current behavior, the desktop essentially becomes useless while someone is in VR, since you cannot click away from the Game view.

[JiaUnity]

So, this is VR specific? Should have pointed this out in the first place.

[jackpr-unity]

@DrummerB 's point, if I understand it correctly, is that there are iteration workflows that require input to be handled when the game view is not selected.

VR is an example they give, but you could iterate using a game controller or other device as well.

[JiaUnity]

Filed: https://issuetracker.unity3d.com/product/unity/issues/guid/1166763/
Closing.

[DrummerB]

VR is an example they give, but you could iterate using a game controller or other device as well.

This is a good point. I think that input should always be processed in the background by default. Keyboard and mouse input being suspended while not in focus should be the special case and not the other way around. Otherwise, you'll run into the same issue with a VR project that uses a regular gamepad, a steering wheel or HOTAS controllers for input. But even for non-VR games, I think it's counterintuitive if gamepad controls are suspended without focus.

[jackpr-unity]

There is a setting on the InputDebugger that forces focus in the editor. If you navigate to Window->Analysis->Input Debugger, click on the options button, and check "Lock Input to Game View"

@flame99999 - does this solve your issue?