WK2 support for gamepads

• Component: WebKit2
• Status: RESOLVED FIXED

[Brady Eidson]

WK2 support for gamepads

This will involve a GamepadProvider in the UIProcess that talks to WebProcesses.  This is necessary because:

1 - Sandbox'ed WebProcesses might not have direct access to the gamepad hardware
2 - Only one process should be monitoring connect/disconnect/input events on behalf of everybody, for efficiencies sake.
3 - If different WebProcesses did their own monitoring then their views of gamepad state would all be out of sync with each other.

I have a mega patch that does all of this by having the UIProcess dump gamepad state into SharedMemory, which the WebProcesses then read out of.  It works well in practice.  It needs some cleanup and to be split into pieces, for which I'll file sub-bugs here.

[Brady Eidson]

Additional design details, just for the record:

- WebCore already has "GamepadProvider", and allows for a platform-specific subclass.  e.g. the HIDGamepadProvider on Mac.
- That platform specific provider works great in WK1, but doesn't work in WK2 for all the reasons mentioned above.
- In WK2, the UIProcess will have a GamepadProviderClient called "WebGamepadProvider" which hooks directly in to the platform provider.  e.g., on Mac, WebGamepadProvider will be a client of the HIDGamepadProvider.
- That WebGamepadProvider will track the individual PlatformGamepads (e.g. HIDGamepads) by mapping them to UIProcess-side "WebGamepad" objects.
- Then the WebProcess will have a generic "WebGamepadProviderProxy" - the same on all platforms - which messages back and forth to the WebGamepadProvider for most of its needs.
- The WebGamepadProviderProxy has to vend PlatformGamepads to WebCore, and its PlatformGamepads will be "WebGamepadProxy" objects.
- The relationship between WebGamepad in the UIProcess and WebGamepadProxy in the WebProcess is that the WebGamepad dumps its gamepad state into a block of shared memory, and the WebGamepadProxy reads state out of that block of shared memory.