Known differences

The few places where migrated input behaves differently from the legacy Input Manager, measured against real input, and what to do about each.

Input Porter is coming soon to the Unity Asset Store. This guide describes the release being prepared.

The bridge is checked frame by frame against the legacy Input Manager: under real keyboard and mouse input on Windows and Linux, a real Xbox controller on Windows, and real touch and accelerometer input on Android (iOS has not been tested yet). Keys, buttons, axes (smoothing included), typed text, ResetInputAxes, mouse position, touches, and acceleration match exactly in Update. These are the differences that remain. Each has been measured, and none is hidden.

Input read in FixedUpdate or OnGUI arrives one frame later

The largest one, and the scan lists every place it applies. Your code keeps working; the press or movement reaches it about 16 ms later at 60 fps. The fix is a small change that is also better practice with the legacy Input Manager. See Input read in FixedUpdate or OnGUI.

Scroll wheels that send small steps (Windows)

Legacy input counts every wheel message as one notch, however small. The Input System reports only the total for the frame. An ordinary mouse wheel sends a whole notch per message, and matches exactly even when spun fast. Smooth-scrolling wheels and precision touchpads send several small steps. When several arrive in one frame, migrated code sees fewer notches than legacy did, so scrolling can feel slower.

Mouse movement after an absolute pointer move (Windows)

Remote Desktop, many virtual machines, and pen tablets in absolute mode move the pointer to a position rather than by an amount. Legacy input reports no mouse movement for these moves. The Input System reports one large movement for that frame. A first-person camera driven by Mouse X / Mouse Y can jump once when the pointer moves this way. Ordinary mice are not affected.

mousePosition before the first mouse movement (platforms other than Windows)

If the pointer moves over your game window while it is not focused, legacy input follows it. On some Unity versions the Input System does not, until the mouse next moves. We measured this on Linux with Unity 6000.6; with Unity 6000.3 the two already match. On Windows the bridge reads the operating system’s cursor directly and matches legacy exactly. It only matters for a game that reads mousePosition before the player has moved the mouse. Input Porter does not change the Input System’s Background Behavior setting: it decides what the whole game does with input while unfocused. If you change it, test your game on each platform you ship.

Keypad keys with NumLock off

With NumLock off, legacy input reports the keypad’s number keys as navigation keys (Insert, End, the arrows, and nothing for keypad 5), so keypad 4 and 6 move a Horizontal axis. The Input System reports the physical keypad keys and does not expose NumLock. If your game uses keypad keys as arrows, bind the arrow keys too.

Gamepad sticks and buttons during fast input

Legacy input reads an Xbox-style controller once per frame. The Input System reads it on its own schedule, a few milliseconds apart. Button numbers, axis numbers, dead zones, and values at rest all match. While a stick moves quickly, the value your code reads can be slightly different; over Bluetooth, about one change in every 27 frames arrives one frame (about 16 ms) later. Leave the Input System’s polling frequency at its default: lowering it makes this larger.

Input.GetJoystickNames() reports an Xbox controller on Windows as “Controller (Xbox One For Windows)”, the name legacy input gives a wired one. Over Bluetooth, legacy input returned an empty or garbled name for the same controller.

Accelerometer samples per frame (mobile)

Input.acceleration matches on almost every frame. The individual samples behind accelerationEventCount and accelerationEvents are the same readings, but the Input System receives them on its own schedule. A sample can arrive a frame earlier or later than it did in legacy, so the count in a given frame can differ. The difference is largest in the first frames after the game starts, when legacy delivers a backlog. On the rare frame where a sample arrives a frame apart, acceleration is the neighbouring sample, a few thousandths of a g away. Code that reads acceleration, or averages the samples over time, is not noticeably affected.

Sensors & IME

Gyroscope, compass, location, IME composition, pen events, and a few mobile settings (deviceOrientation, backButtonLeavesApp) have no automatic equivalent in LegacyInput. The Scan Report lists every use under Sensors & IME. They block the switch to Input System only until they are moved to the Input System’s own APIs, or you keep Active Input Handling on Both. In the migration window, Details… on each row shows the replacement, with code before and after.

Keyboard layouts with AltGr

On Windows, a layout with AltGr (German, French, Polish, US-International, and others) makes Right Alt also press Left Ctrl, and legacy input reports both. The bridge does the same, so an axis bound to left ctrl (like the default Fire1) fires on AltGr exactly as it did. Measured on US-International. Other AltGr layouts are expected to behave the same, and will be listed here once measured.

×