Custom brightness VCP field is gated on features[0x10], so it never appears for the monitors that need it

[rafaelcaraballo-habi]

Summary

The per-monitor custom brightness VCP code field is only rendered when the monitor already reports 0x10 as supported. That is the exact condition under which the field isn't needed — and it's never rendered for the monitors that do need it.

Details

In src/components/MonitorFeatures.jsx:39:

// Brightness (with VCP Code Selection in expanded section)
if (monitor.features["0x10"]) {
    const currentBrightnessVCP = window.settings?.userDDCBrightnessVCPs?.[monitor?.hwid?.[1]] || ""
    extraHTML.push(
        <SettingsOption ... title={T.t("PANEL_LABEL_BRIGHTNESS")} expandable={true}>
            <SettingsChild>
                <BrightnessFeatureSettings hwid={monitor?.hwid?.[1]} ... />

BrightnessFeatureSettings is the only UI surface for userDDCBrightnessVCPs, and it lives inside a block guarded by monitor.features["0x10"].

The feature exists to let users override the brightness code when auto-detection picks the wrong one or finds nothing. But when detection finds nothing, features["0x10"] is false, the Brightness section never renders, and the override is unreachable from the UI.

Concrete case

A Sceptre M27 reports a truncated capabilities string that omits 0x10, so it ends up with:

{
  "name": "Sceptre M27",
  "type": "none",
  "ddcciSupported": true,
  "highLevelSupported": { "brightness": true, "contrast": true },
  "features": { "0x10": false, "0x13": false, "0x12": false, "0xD6": false, "0x60": false, "0x62": false },
  "brightnessType": false
}

The monitor accepts 0x10 reads and writes perfectly — the capabilities string is just wrong. Setting "userDDCBrightnessVCPs": { "SPT0ACD": "0x10" } fixes it completely, but the only way to get there is by hand-editing settings.json.

Suggested fix

Render the brightness VCP override whenever the display is a DDC/CI candidate rather than when 0x10 is already known-good — e.g.:

if (monitor.features["0x10"] || monitor.ddcciSupported || monitor.highLevelSupported?.brightness) {

That keeps current behavior for working monitors while making the escape hatch reachable for the ones it was built for.

Environment

• Twinkle Tray v1.17.2
• Windows 11 Pro 26200

Related

PR #1301 adds a monitor-rules.json entry for this specific display, but the UI gap affects any monitor with a misreported capabilities string.

🤖 Generated with Claude Code