Configuring canRunInBackground for a custom InputDevice

I'm creating a custom InputDevice subclass and I need to be able to configure it using InputDevice.canRunInBackground as described in the documentation. The property is read only and ExecuteCommand cannot be overridden so I'm not sure how to make it happen.

 

any luck with this? **EDIT**

IF you copy the input system package to the local packages folder you can modify InputManager (or InputDevice) to either skip the run in background check or make it assignable. Seems to work for my needs here.

 

I'd seen other forum posts that suggested modifying InputSystem itself but I'm really trying to avoid having to do that as it will most likely cause problems during future upgrades.

 

@Rene-Damm do you have any input on this?

our specific use-case are 3d mice we want to use to navigate the _scene view_ but input only gets through if the game view is focussed which is sub-optimal ux-wise

 

As of 1.1-pre.6 (just released), this can now be set through the layout and through

InputControlLayoutAttribute

.

Code (CSharp):

1. [InputControlLayout(canRunInBackground = true)]
2. public class MyDevice : InputDevice
3. {
4.     // ...

 

Note there's also a pretty significant overhaul that landed of how focus is handled. Also has some implications for the Game View in the editor while in play mode.

 

@Rene-Damm thanks for your quick input.

Through some thorough testing we just found out the 3d mice package ran just fine in 2020.3.8f and breaks in 2020.3.15f (and .16f)

I confirmed it is unrelated to the InputSystem version (both 1.0.2) and other packages. So it has to be something editor-native...?

So is this something that happened inside the InputSystem or inside the editor's codebase?

 

Just tested this and for the described use-case it does not work :/ The behaviour is still the same:

State events only coming through as long as GameView has focus, when SceneView gets focus there is _exactly one_ state event coming through and then silence. The cumulated state events get processed as soon as GameView receives focus again.

 

Breaks in what way? Device not discovered at all anymore or no input coming through?

Inside the package.

What's the base class you are using? With the default setting, pointers (Mouse, Pen, Touchscreen) and keyboard will respect game view focus while anything else won't.

Also, is this in play mode or outside? What kind of script (MonoBehavior? ExecuteInEditMode? EditorWindow?) is picking up input?

 

State events only coming through as long as GameView has focus, when SceneView gets focus there is _exactly one_ state event coming through and then silence. The cumulated state events get processed as soon as GameView receives focus again.

Ok strange. As said, the bug happens with 2020.3.15f but _not_ with 2020.3.8f even _with all packages at the exact same version_. There must be a breaking change somewhere else. Maybe window handling? Or related to the windows message pump? Not something you'd expect from an LTS version though...

InputDevice

Both. It is inside a Editor update event callback:

Code (CSharp):

1. [InitializeOnLoad]
2. class ViewportController
3. {
4.         static ViewportController()
5.         {
6.             EditorApplication.update += Update;
7.         }
8.  
9.         void Update()
10.         {
11.                 // read device values and apply to sceneview camera
12.         }
13. }

(See here for the full class code)

Worked on 2020.3.8f in both edit and play mode.

 

Here's a video trying to demonstrate the behaviour:

First, GameView has focus and i move the 3D mouse.
Then I clear the InputDebug window and focus the SceneView.
Now I move the 3D mouse again continuously and just one event shows up.

 

Would greatly appreciate if you could send your project along through the Unity bug reporter and post the ticket number. Would be great to have a look.

Does indeed sound like a proper regression in native.

 

@Rene-Damm here you go: 1360170
Is that enough or do you need anything else? (Besides maybe the hardware)

 

Hi, I'm the author of the github / asset store project in question.
The issue occurs on head of the master branch.
There's an issue report on github with some more details on which Unity/InputSystem versions it occurs.
https://github.com/PatHightree/SpaceNavigator/issues/36

 

Thank you @cp- for filing for the ticket and thanks @PatHightree for the links. Raised the issue internally. We're not aware of a change here so most likely some change elsewhere that had an unintended side-effect. Digging.

 

Is there any update on this?

 

Sorry, no update yet. But made sure this gets looked at.

 

I just wanted to drop the link to the issue tracker here:
https://issuetracker.unity3d.com/product/unity/issues/guid/1360170

Feel free to cast your vote!

 

I wanted to poke this thread to see if there is any update to this problem.

 

Hi, any update?

Also, @Rene-Damm, I assume canRunInBackground attribute you cited before:

Code (CSharp):

1. [InputControlLayout(canRunInBackground = true)]

Doesn't exist anymore right? Since I can't find it in the InputControlLayout document. Is there a way now to allow an input device to run in the background?