In 1.0.0-preview.8 we have made the Event System component compatible with the new Input System. By default, UI Toolkit’s runtime event loop relies on IMGUI events and the legacy Input Manager to get its data. However, Unity now offers a way for users to use a new Input System paradigm, through the com.unity.inputsystem package, and an option to disable use of the legacy Input Manager completely. Since Unity encourages its users to try out the new Input System paradigm whenever possible, we want UI Toolkit to offer a graceful, out-of-the-box integration with that system. For our first stable version of the UI Toolkit runtime EventSystem component, we want our users to have a single component that automatically detects which Input System paradigm is in use and connects its event loop to the appropriate underlying data. The EventSystem Component Default implementation (with old Input Manager) Up to release 1.0.0-preview.6, the only way for UI Toolkit runtime users to receive events was through the EventSystem component, which allowed them to remap a few of the standard input sources through InputManager axis and button names. Starting from release 1.0.0-preview.8, users are now able to continue using UI Toolkit when the legacy Input Manager is disabled. We implemented an Input System-based version of the EventSystem component, swapping the implementation under the hood and providing a tailored custom Inspector, to make the user’s transition to the new Input System as transparent as possible. Note that the component is exactly the same, no user action is required to replace one by the other, and the new Input System version is automatically chosen whenever the new Input System is available, i.e. both the package is detected and the Player Settings input mode is set to anything other than “Input Manager (Old)”. In the code, a combination of UNITY_INPUT_SYSTEM and ENABLE_INPUT_SYSTEM compilation flags are tested to enable the sections that apply to the new Input System. New Input System implementation This version of component is inspired by the Input System implementation of UGUI’s Input Module (https://docs.unity3d.com/Packages/c....InputSystem.UI.InputSystemUIInputModule.html). The emphasis is on the Input Action Asset field which serves as a starting point for configuring all the various input actions in accordance with the new Input System paradigm. Actions that aren’t configured can be left to “None”, in which case the action will never occur. Once the Input Action asset is configured, a number of standard UI Toolkit actions can be directed to this asset: Navigate is a Vector2 input equivalent to the “Horizontal“ and “Vertical” axes in the regular Event System. So are Submit and Cancel. The Tab action offers a way to remap what input drives the focus navigation towards the next or previous focusable element of the Panel. The Point action triggers PointerMoveEvents The Click, Middle Click and Right Click actions trigger PointerDownEvents and PointerUpEvents, according to their “pressed” state The Scroll Wheel action triggers WheelEvents The other fields are: Repeat Delay: Delay in seconds before a navigation or keyboard event starts repeating if input control is held down. Repeat Rate: Delay in seconds between successive repeated navigation or keyboard events after the first one. Fallback on IMGUI Keyboard Events: Enable this to get KeyDown and KeyUp events directly from IMGUI Event queue for maximal backwards compatibility. Note that future versions of the UI Toolkit package may invalidate the serialization format of the new EventSystem component and lead to some loss of user configuration, until the component adopts a more permanent serialization convention. The current version relies heavily on the use of #if to detect the new Input System package, and may not retain any of the configurations from the regular EventSystem component when the internal implementation and custom inspector are replaced. --- Unblocking users already working with the new Input System was primary goal, but we're curious to hear about what you'd expect to see from a UI Toolkit and Input System integration.