Unity-Technologies · josepmariapujol-unity · Jan 13, 2026 · Jan 9, 2026 · Jan 9, 2026
diff --git a/Packages/com.unity.inputsystem/InputSystem/Actions/InputActionTrace.cs b/Packages/com.unity.inputsystem/InputSystem/Actions/InputActionTrace.cs
@@ -6,19 +6,6 @@
 using Unity.Collections.LowLevel.Unsafe;
 using UnityEngine.InputSystem.LowLevel;
 
-////REVIEW: why not switch to this being the default mechanism? seems like this could allow us to also solve
-////        the actions-update-when-not-expected problem; plus give us access to easy polling
-
-////REVIEW: should this automatically unsubscribe itself on disposal?
-
-////TODO: make it possible to persist this same way that it should be possible to persist InputEventTrace
-
-////TODO: make this one thread-safe
-
-////TODO: add random access capability
-
-////TODO: protect traces against controls changing configuration (if state layouts change, we're affected)
-
 namespace UnityEngine.InputSystem.Utilities
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/Actions/InputBindingComposite.cs b/Packages/com.unity.inputsystem/InputSystem/Actions/InputBindingComposite.cs
@@ -6,15 +6,6 @@
 using UnityEngine.InputSystem.Utilities;
 using UnityEngine.Scripting;
 
-////TODO: support nested composites
-
-////REVIEW: composites probably need a reset method, too (like interactions), so that they can be stateful
-
-////REVIEW: isn't this about arbitrary value processing? can we open this up more and make it
-////        not just be about composing multiple bindings?
-
-////REVIEW: when we get blittable type constraints, we can probably do away with the pointer-based ReadValue version
-
 namespace UnityEngine.InputSystem
 {
     ////TODO: clarify whether this can have state or not

diff --git a/Packages/com.unity.inputsystem/InputSystem/Controls/InputControl.cs b/Packages/com.unity.inputsystem/InputSystem/Controls/InputControl.cs
@@ -8,26 +8,6 @@
 using Unity.Collections.LowLevel.Unsafe;
 using UnityEngine.InputSystem.Layouts;
 
-////REVIEW: should EvaluateMagnitude() be called EvaluateActuation() or something similar?
-
-////REVIEW: as soon as we gain the ability to have blittable type constraints, InputControl<TValue> should be constrained such
-
-////REVIEW: Reading and writing is asymmetric. Writing does not involve processors, reading does.
-
-////REVIEW: While the arrays used by controls are already nicely centralized on InputDevice, InputControls still
-////        hold a bunch of reference data that requires separate scanning. Can we move *all* reference data to arrays
-////        on InputDevice and make InputControls reference-free? Most challenging thing probably is getting rid of
-////        the InputDevice reference itself.
-
-////REVIEW: how do we do stuff like smoothing over time?
-
-////TODO: allow easier access to the default state such that you can easily create a state event containing only default state
-
-////TODO: come up with a way where we do ReadValue on the most common forms/setups of controls and not have any virtual method dispatch but
-////      rather go with minimal overhead directly to reading out memory
-////      (this should at least cover FLT, single BIT, and INT controls; and should be able to apply the common transformations
-////      as per AxisControl)
-
 namespace UnityEngine.InputSystem
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/Controls/InputControlLayout.cs b/Packages/com.unity.inputsystem/InputSystem/Controls/InputControlLayout.cs
@@ -8,55 +8,6 @@
 using UnityEngine.InputSystem.LowLevel;
 using UnityEngine.InputSystem.Utilities;
 
-////TODO: *kill* variants!
-
-////TODO: we really need proper verification to be in place to ensure that the resulting layout isn't coming out with a bad memory layout
-
-////TODO: add code-generation that takes a layout and spits out C# code that translates it to a common value format
-////      (this can be used, for example, to translate all the various gamepad formats into one single common gamepad format)
-
-////TODO: allow layouts to set default device names
-
-////TODO: allow creating generic controls as parents just to group child controls
-
-////TODO: allow things like "-something" and "+something" for usages, processors, etc
-
-////TODO: allow setting whether the device should automatically become current and whether it wants noise filtering
-
-////TODO: ensure that if a layout sets a device description, it is indeed a device layout
-
-////TODO: make offset on InputControlAttribute relative to field instead of relative to entire state struct
-
-////REVIEW: common usages are on all layouts but only make sense for devices
-
-////REVIEW: useStateFrom seems like a half-measure; it solves the problem of setting up state blocks but they often also
-////        require a specific set of processors
-
-////REVIEW: Can we allow aliases to be paths rather than just plain names? This would allow changing the hierarchy around while
-////        keeping backwards-compatibility.
-
-// Q: Why is there this layout system instead of just new'ing everything up in hand-written C# code?
-// A: The current approach has a couple advantages.
-//
-//    * Since it's data-driven, entire layouts can be represented as just data. They can be added to already deployed applications,
-//      can be sent over the wire, can be analyzed by tools, etc.
-//
-//    * The layouts can be rearranged in powerful ways, even on the fly. Data can be inserted or modified all along the hierarchy
-//      both from within a layout itself as well as from outside through overrides. The resulting compositions would often be very
-//      hard/tedious to set up in a linear C# inheritance hierarchy and likely result in repeated reallocation and rearranging of
-//      already created setups.
-//
-//    * Related to that, the data-driven layouts make it possible to significantly change the data model without requiring changes
-//      to existing layouts. This, too, would be more complicated if every device would simply new up everything directly.
-//
-//    * We can generate code from them. Means we can, for example, generate code for the DOTS runtime from the same information
-//      that exists in the input system but without depending on its InputDevice C# implementation.
-//
-//    The biggest drawback, other than code complexity, is that building an InputDevice from an InputControlLayout is slow.
-//    This is somewhat offset by having a code generator that can "freeze" a specific layout into simple C# code. For these,
-//    the result is code at least as efficient (but likely *more* efficient) than the equivalent in a code-only layout approach
-//    while at the same time offering all the advantages of the data-driven approach.
-
 namespace UnityEngine.InputSystem.Layouts
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/Devices/Pointer.cs b/Packages/com.unity.inputsystem/InputSystem/Devices/Pointer.cs
@@ -5,26 +5,6 @@
 using UnityEngine.InputSystem.Utilities;
 using UnityEngine.Scripting;
 
-////TODO: add capabilities indicating whether pressure is supported
-
-////REVIEW: is there an opportunity to collapse "press" and "pressure" into one? after all, if there's any pressure, isn't the pointer pressed?
-
-////REVIEW: should "displayIndex" be called "windowIndex"? or be part of a better thought-out multi-display API altogether?
-
-////REVIEW: add click and clickCount controls directly to Pointer?
-////        (I gave this a look but in my initial try, found it somewhat difficult to add click detection at the Pointer level due
-////        to the extra state it involves)
-
-////REVIEW: should we put lock state directly on Pointer?
-
-////REVIEW: should pointer IDs be required to be globally unique across pointing devices?
-////REVIEW: should we create new devices instead of using pointer IDs?
-
-////FIXME: pointer deltas in EditorWindows need to be Y *down*
-
-////REVIEW: kill EditorWindowSpace processor and add GetPositionInEditorWindowSpace() and GetDeltaInEditorWindowSpace()?
-////        (if we do this, every touch control has to get this, too)
-
 namespace UnityEngine.InputSystem.LowLevel
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs b/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs
@@ -8,25 +8,6 @@
 using UnityEngine.InputSystem.Utilities;
 using Unity.Profiling;
 
-////TODO: property that tells whether a Touchscreen is multi-touch capable
-
-////TODO: property that tells whether a Touchscreen supports pressure
-
-////TODO: add support for screen orientation
-
-////TODO: touch is hardwired to certain memory layouts ATM; either allow flexibility or make sure the layouts cannot be changed
-
-////TODO: startTimes are baked *external* times; reset touch when coming out of play mode
-
-////TODO: detect and diagnose touchId=0 events
-
-////REVIEW: where should we put handset vibration support? should that sit on the touchscreen class? be its own separate device?
-
-////REVIEW: Given that Touchscreen is no use for polling, should we remove Touchscreen.current?
-
-////REVIEW: Should Touchscreen reset individual TouchControls to default(TouchState) after a touch has ended? This would allow
-////        binding to a TouchControl as a whole and the action would correctly cancel if the touch ends
-
 namespace UnityEngine.InputSystem.LowLevel
 {
     [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1028:EnumStorageShouldBeInt32", Justification = "byte to correspond to TouchState layout.")]

diff --git a/Packages/com.unity.inputsystem/InputSystem/InputManager.cs b/Packages/com.unity.inputsystem/InputSystem/InputManager.cs
@@ -28,22 +28,6 @@
 using CustomBindingPathValidator = System.Func<string, System.Action>;
 #endif
 
-////TODO: make diagnostics available in dev players and give it a public API to enable them
-
-////TODO: work towards InputManager having no direct knowledge of actions
-
-////TODO: allow pushing events into the system any which way; decouple from the buffer in NativeInputSystem being the only source
-
-////REVIEW: change the event properties over to using IObservable?
-
-////REVIEW: instead of RegisterInteraction and RegisterProcessor, have a generic RegisterInterface (or something)?
-
-////REVIEW: can we do away with the 'previous == previous frame' and simply buffer flip on every value write?
-
-////REVIEW: should we force keeping mouse/pen/keyboard/touch around in editor even if not in list of supported devices?
-
-////REVIEW: do we want to filter out state events that result in no state change?
-
 #pragma warning disable CS0649
 namespace UnityEngine.InputSystem
 {

diff --git a/Packages/com.unity.inputsystem/InputSystem/InputSettings.cs b/Packages/com.unity.inputsystem/InputSystem/InputSettings.cs
@@ -6,26 +6,6 @@
 using UnityEngine.InputSystem.Processors;
 using UnityEngine.InputSystem.Utilities;
 
-////TODO: make sure that alterations made to InputSystem.settings in play mode do not leak out into edit mode or the asset
-
-////TODO: handle case of supportFixedUpdates and supportDynamicUpdates both being set to false; should it be an enum?
-
-////TODO: figure out how this gets into a build
-
-////TODO: allow setting up single- and multi-user configs for the project
-
-////TODO: allow enabling/disabling plugins
-
-////REVIEW: should the project settings include a list of action assets to use? (or to force into a build)
-
-////REVIEW: add extra option to enable late-updates?
-
-////REVIEW: put default sensor sampling frequency here?
-
-////REVIEW: put default gamepad polling frequency here?
-
-////REVIEW: Have an InputActionAsset field in here that allows having a single default set of actions that are enabled with no further setup?
-
 namespace UnityEngine.InputSystem
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs b/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs
@@ -28,27 +28,6 @@
 using CustomBindingPathValidator = System.Func<string, System.Action>;
 #endif
 
-////TODO: allow aliasing processors etc
-
-////REVIEW: rename all references to "frame" to refer to "update" instead (e.g. wasPressedThisUpdate)?
-
-////TODO: add APIs to get to the state blocks (equivalent to what you currently get with e.g. InputSystem.devices[0].currentStatePtr)
-
-////FIXME: modal dialogs (or anything that interrupts normal Unity operation) are likely a problem for the system as is; there's a good
-////       chance the event queue will just get swamped; should be only the background queue though so I guess once it fills up we
-////       simply start losing input but it won't grow infinitely
-
-////REVIEW: make more APIs thread-safe?
-
-////REVIEW: it'd be great to be able to set up monitors from control paths (independently of actions; or should we just use actions?)
-
-////REVIEW: have InputSystem.onTextInput that's fired directly from the event processing loop?
-////        (and allow text input events that have no associated target device? this way we don't need a keyboard to get text input)
-
-////REVIEW: split lower-level APIs (anything mentioning events and state) off into InputSystemLowLevel API to make this API more focused?
-
-////TODO: release native allocations when exiting
-
 namespace UnityEngine.InputSystem
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/Plugins/Steam/SteamIGAConverter.cs b/Packages/com.unity.inputsystem/InputSystem/Plugins/Steam/SteamIGAConverter.cs
@@ -9,23 +9,6 @@
 using UnityEngine.InputSystem.Editor;
 using UnityEngine.InputSystem.Utilities;
 
-////TODO: motion data support
-
-////TODO: haptics support
-
-////TODO: ensure that no two actions have the same name even between maps
-
-////TODO: also need to build a layout based on SteamController that has controls representing the current set of actions
-////      (might need this in the runtime)
-
-////TODO: localization support (allow loading existing VDF file and preserving localization strings)
-
-////TODO: allow having actions that are ignored by Steam VDF export
-
-////TODO: support for getting displayNames/glyphs from Steam
-
-////TODO: polling in background
-
 namespace UnityEngine.InputSystem.Steam.Editor
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/State/InputStateBlock.cs b/Packages/com.unity.inputsystem/InputSystem/State/InputStateBlock.cs
@@ -3,22 +3,6 @@
 using Unity.Collections.LowLevel.Unsafe;
 using UnityEngine.InputSystem.Utilities;
 
-////TODO: the Debug.Asserts here should be also be made as checks ahead of time (on the layout)
-
-////TODO: the read/write methods need a proper pass for consistency
-
-////FIXME: some architectures have strict memory alignment requirements; we should honor them when
-////       we read/write primitive values or support stitching values together from bytes manually
-////       where needed
-
-////TODO: allow bitOffset to be non-zero for byte-aligned control as long as result is byte-aligned
-
-////REVIEW: The combination of byte and bit offset instead of just a single bit offset has turned out
-////        to be plenty awkward to use in practice; should be replace it?
-
-////REVIEW: AutomaticOffset is a very awkward mechanism; it's primary use really is for "parking" unused
-////        controls for which a more elegant and robust mechanism can surely be devised
-
 namespace UnityEngine.InputSystem.LowLevel
 {
     /// <summary>

diff --git a/Packages/com.unity.inputsystem/InputSystem/State/InputStateHistory.cs b/Packages/com.unity.inputsystem/InputSystem/State/InputStateHistory.cs
@@ -9,14 +9,6 @@
 using UnityEngine.InputSystem.LowLevel;
 using UnityEngine.InputSystem.Utilities;
 
-////REVIEW: should this enumerate *backwards* in time rather than *forwards*?
-
-////TODO: allow correlating history to frames/updates
-
-////TODO: add ability to grow such that you can set it to e.g. record up to 4 seconds of history and it will automatically keep the buffer size bounded
-
-////REVIEW: should we align the extra memory on a 4 byte boundary?
-
 namespace UnityEngine.InputSystem.LowLevel
 {
     /// <summary>