I think we can remove this dependency if we make GamepadDataFetcher an async mojo interface.  ContentViewCore would have its own GamepadDataFetcher implementation that only depends on the public interface.


ContentViewCore uses five GamepadList methods:

isGamepadAPIActive

Returns true if the Gamepad API is active. The API is paused when there are no active gamepad consumers. The event initially comes from GamepadService, which then asks the GamepadProvider to call PauseHint on all its GamepadDataFetchers on the polling thread. With a GamepadDataFetcher mojo interface, ContentViewCore could implement its own GamepadDataFetcher to receive the PauseHint event directly instead of through JNI.

dispatchKeyEvent and onGenericMotionEvent

These methods handle gamepad button and axis events. ContentViewCore's GamepadDataFetcher should update its gamepad state and store the state in a shared memory buffer. The buffer should use the mojo Gamepad struct type instead of GamepadDevice. GamepadProvider would poll this buffer instead of calling fetcher->GetGamepadData synchronously.

onAttachedToWindow and onDetachedFromWindow

These are called when the ContentViewCore is attached to/detached from a window, initializing/clearing the GamepadDevice buffers and (un)registering the InputDevice listener. Neither requires communicating with the GamepadService.

There's also the issue of GamepadMappings.java. Currently, the GamepadDataFetcher is responsible for choosing the appropriate mapping. If the fetcher is now a client interface to the device service, it would make more sense for the mapping to be handled internally. To make this possible, the fetcher would also include the VID/PID pair when reporting the gamepad state to the provider, and the provider would be responsible for choosing the mapping function.

The proposed design seems promising to me, I'm not qualified to comment on it in detail. I think bajones@ is likely the right person? 

Discussed this with reillyg@, he suggested that we not add another mojo interface between gamepad events and the renderer. Instead, we should try to find a way to get the button and axis events independently of the ContentView. Currently we rely on ContentView for its View callbacks, but it might be possible to get the gamepad events from another source.