Mouse emulation to address MSFS issues

This section introduces the custom mouse-emulation features that fsmapper provides to work around a limitation in Microsoft Flight Simulator (MSFS), where certain popup windows cannot be operated by touch.

Depending on your hardware environment, some amount of tuning may be required. You may also want to adjust the emulation behavior to achieve better responsiveness for your workflow. For this reason, fsmapper exposes a wide range of parameters that allow fine-grained control over how touch input is translated into mouse events. Understanding the nature of the MSFS touch-handling issue, and how each parameter influences that behavior, will help you optimize the settings for your particular configuration.

This section begins with an explanation of the underlying touch-input problem in MSFS and how fsmapper addresses it. It then describes each of the available tuning parameters. Finally, it provides recommended configurations.

MSFS issues and fsmapper approach

It is a well-known issue that when you pop-out touch-enabled avionics windows in MSFS, such as the G3X Touch or the G5000 GTC, they become operable with a mouse but no longer respond to touch input. Microsoft has never published an official explanation, but my working theory is that the fallback mouse events generated by Windows do not align well with the timing assumptions inside MSFS’s mouse-state handling logic. As a result, MSFS may fail to interpret the intended mouse-state transitions correctly when touch input is involved.

Based on this assumption, fsmapper implements its own mouse-emulation layer that generates mouse events at timing intervals MSFS can reliably interpret. In practice, this approach has proven effective and restores touch operability for popped out avionics windows.

Technically, fsmapper emulates mouse input in two stages:

• A DLL injected into the MSFS process (specifically, into the process that owns any window specified by CapturedWindow) monitors touch events (WM_POINTERDOWN, WM_POINTERUP, WM_POINTERUPDATE) and generates corresponding mouse events using SendInput() at carefully controlled timings.
• To prevent MSFS from misbehaving due to a mixture of emulated events and Windows-generated fallback mouse messages, a WH_MOUSE_LL hook is used to filter out the fallback events before they reach MSFS.

MSFS constraints relevant to mouse emulation

Through extensive testing, several important behavioral constraints became clear:

• A successful tap must consist of three events, cursor move → left button down → left button up—and all must occur at the exact same cursor location. Even slight movement between down and up of left button causes MSFS to ignore the input.
• Each event must be spaced apart by tens of milliseconds. Sending events too quickly (e.g., immediately on touch) leads to MSFS ignoring them.
• Conversely, if the press duration (time between down and up of left button) is too long, MSFS may fail to finalize the button action, getting stuck in a visually “pressed” state.
• After a left-button-up event, MSFS requires a minimum interval before it can correctly process another click. Rapid repeated taps must respect this timing.
• Repeated clicks on exactly the same location are prone to being dropped

These constraints form the basis of the configuration parameters described in the following section.

Configuration parameters

This section describes each parameter available for tuning fsmapper’s mouse-emulation behavior. You can access these parameters from:

• Settings → Microsoft Flight Simulator → Mouse emulation for Touch

Delay mouse emulation

When enabled this option, fsmapper does not immediately generate cursor movement or button-down events when a touch begins. Instead, emulation is deferred until either:

• the touch is released, or
• a drag gesture is detected.

At that moment, fsmapper emits the appropriate sequence of events (cursor move, button down if needed, and button up). This mode helps prevent MSFS from missing events that occur too close to each other at touch-down time.

This mode helps mitigate an issue in MSFS where long press-and-release intervals on the left mouse button can cause the simulator to miss events. In most cases, it is recommended to keep this option enabled. However, if you prefer faster input response and are willing to accept the risk of missed events, you may turn it off.

Jitter amount

Specifies a small offset range, in pixels, that is applied when repeatedly tapping the same location on the screen. This helps prevent MSFS from dropping consecutive click sequences that occur without any cursor movement between actions. In addition, a drag gesture will not be recognized unless the touch position moves by at least the number of pixels specified here.

The jitter offset is kept within this maximum pixel value. It is recommended to start with a small number of pixels.

Cursor move delay

The delay, in milliseconds, between detecting a touch and generating the corresponding cursor-move event.
When Delay mouse emulation is enabled, this delay applies after next emulation point (at touch-up or drag start), not at the initial touch point.

Properly spacing actual touch events and emulated cursor-move is essential for MSFS to recognize them reliably.

Cursor move trigger distance

Specifies the minimum distance (in pixels) between the current cursor position and the touch location before fsmapper performs a cursor-move emulation.
A value of 0 forces cursor movement for every touch, regardless of distance.

Touch to click delay

The delay, in milliseconds, between emulated cursor movement event (or, if movement is skipped, touch detection) and the left-button-down event.
MSFS often requires a gap of several tens of milliseconds to reliably process the transition from cursor move to click.

Touch to release delay

The delay, in milliseconds, between lifting your finger and issuing the corresponding left-mouse-button release event.

Drag start delay

The delay, in milliseconds, before generating the first cursor-move event after a drag gesture is detected.
This affects only the starting phase of the drag; continued drag movement is not delayed by this setting.

Drag dead zone

Specifies the allowable finger movement, in pixels, after a touch before a drag gesture is recognized — effectively defining the size of the drag dead zone.
While the Jitter amount parameter provides a similar effect, this parameter is useful when you need a larger dead zone than the offset applied by Jitter amount.

Minimum interval (ms)

Specifies the minimum amount of time that must pass between a left-button-up event and the start of the next emulated click sequence.
Shorter intervals may cause MSFS to drop rapid-fire taps. Longer intervals increase reliability at the cost of responsiveness.

Recommended Settings

Hardware touch displays (true HID digitizers) and software-based remote/virtual touch displays (e.g., Duet Display, Luna Display) behave differently, especially regarding timing and pointer-event generation.

Accordingly, fsmapper provides separate recommended default values for each device type. You can apply these defaults using the following two buttons:

• Reset to Native Default button — optimized for hardware touch displays
• Reset to Remote Default button — optimized for software-based remote/virtual touch displays

The recommended default values provided by fsmapper for each display type are listed below. Use these as a starting point and adjust them as needed to match your environment and personal preferences.

Parameter	Native Touch Display	Remote Touch Display
Delay mouse emulation	On	Off
Jitter amount	3	3
Cursor move delay	80	0
Cursor move trigger distance	0	0
Touch to click delay	50	50
Touch to release delay	50	50
Drag start delay	0	0
Drag dead zone	0	0
Minimum interval	200	0