Bug Report — Philips 34B2U3600C SmartKVM Hotkey Failure (USB-B upstream)

Gepubliceerd: 14 sep 2026 · Laatste wijziging: 14 sep 2026
Complete, ready-to-submit bug report for the Philips 34B2U3600C/00 SmartKVM hotkey defect: the triple-Ctrl hotkey stops responding after one complete KVM switch cycle on the USB-B / HDMI upstream. The plain-text report below can be copied 1:1 into a Philips / MMD support form.
BUG REPORT - Philips 34B2U3600C/00
SmartKVM hotkey (triple-Ctrl) stops responding after one complete KVM switch cycle on the USB-B / HDMI upstream

PRODUCT
- Model:            Philips 34B2U3600C/00 (34" Curved Business Monitor 3000 series)
- Serial number:    UK02620006084
- Product code:     4124 (0x101c)
- Manufactured:     week 20, 2026
- Firmware:         factory (unit has never been updated; version unknown - SmartControl does not expose a firmware section for this unit, see Request)
- Report date:      2026-09-14

SUMMARY
The KVM Smart hotkey (triple-press Ctrl) works reliably for exactly one complete switch cycle after a monitor power cycle. After the upstream has been switched once in each direction, the hotkey becomes unresponsive while the USB-B / HDMI host is the active source. Video and USB data keep working normally; only hotkey detection fails. Power-cycling the monitor restores the hotkey, after which the identical pattern repeats.

CONNECTIONS
- USB-C1 (DP alt mode, 90W PD): MacBook Pro M1 16" - video + USB upstream (macOS, current release)
- HDMI:                         Lenovo ThinkPad X1 Carbon Gen 6 - video (Ubuntu 24.04 LTS, kernel 6.8)
- USB-B ("USB UP"):             ThinkPad - USB upstream for the KVM
- USB-A (3x):                   Apple Magic Keyboard (wired USB-C), Apple Magic Trackpad 2 (wired via Lightning), Logitech Brio 100 (fixed USB-A cable)
- Audio-out:                    active speakers
- USB-C2, RJ45:                unused

The peripherals are verified working on both upstreams at all times (keyboard/trackpad input reaches whichever host is active, even while the hotkey is dead). The defect is isolated to hotkey detection - not to USB routing, video switching or the peripherals.

OSD SETTINGS (as configured during reproduction)
- Input:                        explicit source selection (tested; behaviour identical with automatic selection)
- KVM:                          Auto (explicit USB-C binding also tested)
- USB Setting - USB-C Setting:  High Resolution
- USB Standby Mode:             On
- PIP/PBP:                      not used
- All other settings:           factory default

REPRODUCTION (deterministic; repeated multiple times on 2026-09-14)
1. Power-cycle the monitor (mains off/on). Both hosts connected, awake and docked.
2. Active source = USB-C1 (Mac). Triple-Ctrl on the shared keyboard:
   monitor switches to HDMI (ThinkPad); keyboard/trackpad follow. OK.
3. Active source = HDMI (ThinkPad). Triple-Ctrl:
   monitor switches back to USB-C1 (Mac). OK.
4. Active source = USB-C1 (Mac). Triple-Ctrl:
   monitor switches to HDMI (ThinkPad). OK.
5. Active source = HDMI (ThinkPad). Triple-Ctrl:
   NO RESPONSE. FAIL.
   - USB data path is intact: typing on the shared keyboard still reaches the ThinkPad. Only the hotkey detection is dead.
   - Switching via the OSD input menu still works. After an OSD switch back to USB-C1, the hotkey remains unresponsive once the USB-B host is active again.
6. Power-cycle the monitor: hotkey works again, then fails again after exactly one complete cycle (steps 2-5). Confirmed in multiple consecutive repetitions.

ADDITIONAL OBSERVATIONS
- One day earlier (2026-09-13) the hotkey worked flawlessly for ~10 consecutive switches following a reboot of the USB-B host. The defect is intermittent across days but deterministic within a session: reliable after power-on / fresh enumeration, dead after the hub has been re-bound between upstreams.
- Re-plugging the USB-B cable does NOT restore the hotkey.
- A reboot of the USB-B host (fresh USB enumeration) temporarily restored the hotkey once - consistent with stale KVM/hotkey state after upstream re-enumeration.
- Press cadence does not matter (3 discrete presses within ~1-2 s, tested repeatedly).
- Only factory-supplied cables in use; the supplied USB-C cable was verified to carry USB data (a device enumerated directly on a host using the same cable).

SECONDARY FINDING - DDC/CI Input Source (VCP 0x60) not implemented
The monitor communicates over DDC/CI (VCP 3.0 reported; EDID and serial read correctly via ddcutil 1.4.1 on Linux), but feature 0x60 (Input Source) is not implemented:

    $ ddcutil getvcp 0x60
    VCP code 0x60 (Input Source): Unsupported feature code (DDC NULL Message)

Feature 0x60 is also absent from "ddcutil capabilities". This removes the standard software fallback for input switching on Linux hosts, which would otherwise work around the hotkey defect.

RULED OUT
- Cables: factory-supplied USB-C cable verified data-capable; USB-B cable re-plugged (no effect)
- Hosts: two different hosts / operating systems (macOS and Ubuntu) connected; Linux-side keyboard remapping (keyd) not in use - behaviour identical with vanilla HID
- OSD configuration: KVM = Auto and explicit binding both tested; USB-C Setting = High Resolution; USB Standby Mode = On
- Peripherals: same keyboard works on both upstreams; typing continues to work while the hotkey is dead

IMPACT
Two-host KVM usage requires power-cycling the monitor (or rebooting a host) to regain hotkey switching - which defeats the purpose of SmartKVM.

REQUEST
1. Confirm whether this is a known issue and whether a firmware update addresses the hotkey state machine on the USB-B upstream path.
2. Provide the current/latest firmware version for the 34B2U3600C/00 and instructions for reading the firmware version on this unit (SmartControl does not show a firmware section).
3. Provide the firmware file and instructions for the OTG (USB stick) update route - this unit runs factory firmware and has never been updated.
4. If no fix is available: advise on the RMA procedure.