Hey everyone,
I’m running a modified legacy setup and could use some advice from the MXM / VBIOS modding experts here who know the behavior of these specific workstations.
Hardware Configuration:
Laptop: HP EliteBook 8570w (Ivy Bridge platform)
MXM GPU: NVIDIA Quadro M1000M (Maxwell GM107)
VBIOS Version: 82.07.8D.00.15 (Native HP mobile firmware, Build Date: 2015-10-29, Flashed using the verified HP dump directly from the TPU Database: https://www.techpowerup.com/vgabios/239513/239513)
Display Panel: Original factory-matching 10-bit HP DreamColor assembly (LG Display)
Monitor Hardware ID: MONITOR\LGD0220
Device Manager Name: "Integrated Monitor"
Device Manager Description: "Generic PnP Monitor"
OS & Driver: Windows 11 running in pure UEFI mode (Legacy CSM disabled). Modified driver package (INF patched for Hardware IDs).
The Problem:
The machine boots perfectly through POST/BIOS, but during the Windows 11 login handoff, the NVIDIA driver initializes the panel at a static, dim baseline—not completely blacked out, but noticeably dimmer than what is actually set in the active Windows power plan.
The hardware and driver are completely stable, but the power/brightness state is totally desynced at startup. Interestingly, if I press the physical Brightness Down key once, the screen instantly snaps out of the dim state, restores its original full brightness level from the power plan, and moves down a single notch. This proves the display link and backlighting are completely healthy, but the driver is caching the wrong initial value until a physical hardware interrupt forces it to evaluate the active OS power plan state.
Device Manager Details:
In Device Manager, the screen shows up under the name "Integrated Monitor", but its Device Description field reads "Generic PnP Monitor". This indicates that while Windows recognizes the physical internal routing, the modded NVIDIA driver is failing to map the panel's EDID string correctly on boot, resulting in a generic fallback power state until an interrupt occurs.
Attempting to use low-level software utilities (like sending direct DDC/CI commands via Session 0) to force the brightness value during the boot sequence completely locks up the DreamColor microcontroller, requiring a full battery/CMOS flush to recover physical Fn key control.
What I need help with:
Since the card is running a native HP 82.07.8D.00.15 VBIOS, the state desync is happening strictly during the Windows driver initialization handshake with this specific factory assembly.
Has anyone successfully dealt with this specific boot-up dimming state desync on Maxwell/Pascal card swaps with factory DreamColor boards?
Are there specific registry override strings or advanced INF tweaks (like RM_I2cWriteRegistry, Mobile_Registers, or altering mobile power state bitmasks) that I should inject into the driver package to force the NVIDIA Resource Manager to read the active Windows power plan brightness right at startup?
Alternatively, does this require a deeper edit to the 82.07.8D.00.15 VBIOS's internal display tables or ACPI mappings to ensure it passes the correct voltage profile to Windows during the handoff on older Ivy Bridge motherboards?
Any insight from those who have wrangled with the sensitive hardware handshakes of these DreamColor mapping boards would be greatly appreciated. Thanks!
