Uninitialized display_t members cause garbage touch/absolute input on Windows

[Nonary]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the latest beta/pre-release?

This issue is present in the latest pre-release

Describe the Bug

After commit aca5d23f4 ("fix(linux): fix issues with rendering and touchscreens when displays are scaled", PR #4607), Windows users experience broken multi-touch and absolute mouse input — cursor gets stuck at screen edges, offset to the bottom-right, or locked to one axis.

Regression Source

Commit aca5d23f4 added four new integer fields to platf::display_t in src/platform/common.h:

int env_logical_width, env_logical_height;
int logical_width, logical_height;

These fields are correctly populated on Linux (KMS/Wayland) but never assigned on Windows or macOS.

Root Cause

Bug 1: Uninitialized members (primary)

display_t has a user-provided constructor that only initializes two fields:

display_t() noexcept: offset_x{0}, offset_y{0} {}

Per the C++ standard ([dcl.init] §9.4), members not listed in a user-provided constructor's initializer list are default-initialized — which for scalar types means indeterminate values (heap garbage). Since the four new fields are never assigned on Windows, they retain garbage.

In video.cpp, make_port() guards the logical-scaling path with:

if (display->logical_width && display->logical_height &&
    display->env_logical_width && display->env_logical_height) {

This guard was intended to skip the path on non-Linux platforms where these fields aren't set. However, garbage non-zero values pass the truthiness check, causing:

1. scalar_tpcoords is computed from garbage dimensions → random float value
2. env_logical_width/height are set to garbage → wrong touch port dimensions

Then in input.cpp, client_to_touchport() divides coordinates by garbage scalar_tpcoords, and the abs_mouse passthrough uses garbage env_logical dimensions — producing completely wrong coordinate mapping.

Bug 2: Double-offset in client_to_touchport() (secondary)

The new offset adjustment in client_to_touchport():

float final_x = (x + touch_port.offset_x * touch_port.scalar_tpcoords) / touch_port.scalar_tpcoords;
float final_y = (y + touch_port.offset_y * touch_port.scalar_tpcoords) / touch_port.scalar_tpcoords;

applies display offsets that the Windows/macOS platform layers (abs_mouse, populate_common_pointer_info) already apply, resulting in a double-offset on multi-monitor setups where offset_x != 0.

Symptoms

• Touch/absolute mouse input stuck at screen edge or bottom-right corner
• Cursor movable along only one axis
• Symptoms vary per Sunshine launch (different garbage values each time)
• Most commonly triggered with virtual displays as secondary monitors

Expected Behavior

Touch and absolute mouse input should map correctly to the streamed display on all platforms (Windows, macOS, Linux).

Additional Context

Two changes are required:

1. Initialize all display_t members (src/platform/common.h)

display_t() noexcept:
    offset_x{0}, offset_y{0},
    env_width{0}, env_height{0},
    env_logical_width{0}, env_logical_height{0},
    width{0}, height{0},
    logical_width{0}, logical_height{0} {}

This ensures the guard in video.cpp correctly evaluates to false on platforms that don't set logical dimensions.

2. Guard the offset adjustment for Linux only (src/input.cpp)

#ifdef __linux__
  float final_x = (x + touch_port.offset_x * touch_port.scalar_tpcoords) / touch_port.scalar_tpcoords;
  float final_y = (y + touch_port.offset_y * touch_port.scalar_tpcoords) / touch_port.scalar_tpcoords;
#else
  float final_x = x / touch_port.scalar_tpcoords;
  float final_y = y / touch_port.scalar_tpcoords;
#endif

This prevents double-application of display offsets on platforms where the platform layer already handles them.

Affected Platforms

• Windows — confirmed broken
• macOS — likely affected (same uninitialized fields, same code path)
• Linux — not affected (fields are properly set by KMS/Wayland backends)

Affected Versions

Any version containing commit aca5d23f4 (PR #4607).

This bug has been confirmed and resolved on Vibeshine via user testing, while this issue is entirely AI generated this bug is real and the suggested fixes above actually solve the problem: Nonary#139

Host Operating System

Windows

Operating System Version

25H2

Architecture

amd64/x86_64

Package

Windows - exe installer

GPU Type

NVIDIA

GPU Model

4090

GPU Driver/Mesa Version

Irrelevant

Capture Method

Desktop Duplication API (Windows)

Apps

Log output

Online logs

No response

[ReenigneArcher]

I'm not doubting that this is a potential bug, but does this bug actually exist in Sunshine? Or only in your fork?

It seems unlikely to me it exists in Sunshine without having a single user report this bug, especially considering the PR that introduced this was merged over a month ago.

[Nonary]

I'm not doubting that this is a potential bug, but does this bug actually exist in Sunshine? Or only in your fork?

It seems unlikely to me it exists in Sunshine without having a single user report this bug, especially considering the PR that introduced this was merged over a month ago.

I think it's because, currently only my fork has this commit on the stable release. And also, it is quite niche, it only impacts users that use touch screens. And that the only ones who could be impacted by it with sunshine, would be people who decided to download the pre-release version of sunshine. Which normally people wouldn't do unless there is a feature or bug fix relevant to them.

This issue only really impacts Windows users, and Mac but those are even more rare.

I can't really confirm it only exists in Vibeshine or not, but that would be shocking to me because the bug is pretty clear. There is no room for doubt that it exists or not, at least to me.

[ejelly]

Pretty sure I'm actually seeing this bug, or a very similar one. I'm using pre-release Sunshine on Windows, and the touchscreen input (from my handheld device) seems completely bogus.

[ReenigneArcher]

@ejelly Thanks for confirming! I do not have a touchscreen device to test this out. Could you test out the assets from #4758

You can download the artifacts from: https://github.com/LizardByte/Sunshine/actions/runs/22511461833/artifacts/5700525880