HP EliteBook 8570w + Quadro M1000M MXM + Factory DreamColor Assembly: Persistent Boot-up Dimming State Desync

[akluch]

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.

1. Has anyone successfully dealt with this specific boot-up dimming state desync on Maxwell/Pascal card swaps with factory DreamColor boards?

2. 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?

3. 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!

[loopster]

What driver version are you running?
I'm on 460.89 with M1000M / 82.07.8D.00.15 bios and DC screen on windows 10 64 bit LTSC, no issues whatsoever.

Maybe give 460.89 a try?

[akluch]

6 hours ago, loopster said:

What driver version are you running?
I'm on 460.89 with M1000M / 82.07.8D.00.15 bios and DC screen on windows 10 64 bit LTSC, no issues whatsoever.

Maybe give 460.89 a try?

 

Wow, having someone with the exact same hardware combination reply is massive! Thank you. Knowing that the M1000M + 82.07.8D.00.15 + DreamColor matrix works perfectly for you isolates this completely to a driver branch or OS handoff issue.

I am currently running a much newer driver branch on Windows 11, which I manually modded. Before I attempt to roll back to the 460.89 branch, I would love to verify a couple of quick Registry/INF details from your working system to see where the communication breakdown is happening on mine:

1. Device Manager Identification: On your LTSC setup, does your DreamColor panel show up under Monitors as a "Generic PnP Monitor" linked to MONITOR\LGD0220, or does it map to a specific HP/DreamColor hardware ID wrapper (like HPQ3201)?

2. Registry Injection: If you check your active display registry path under: HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000 Are there any specific mobile registry overrides active (such as Mobile_Registers, RM_I2cWriteRegistry, or target panel power bitmasks)?

If you happen to still have the modified .inf file or the specific setup folder you used to deploy 460.89 on your machine, would you be open to sharing it? I'd love to compare the section blocks to see if your INF maps the eDP/panel power scaling differently than the newer driver branches do. Thanks again!

[loopster]

Uhm, I am terribly sorry for committing the dreadful crime of spreading misinformation😅
 

I WAS INITIALLY running 82.07.8D.00.15 with non a non-DC screen, but at some point (maybe a year ago) I flashed a different vbios

with an applied overclock (1071 to 1306 ) onto my M1000M - version 82.07.97.00.04, since I was too lazy as to mod my own bios...

 

Then two months ago, I got hold of a DC screen, installed that and it worked right of the bat with 82.07.97.00.04 - I hadn't even thought about the different vbios versions...

 

In device manager, screen identifies as 

PnP-Monitor (Standard) 
Hardware ID

MONITOR\LGD0220

No specific mobile registry overrides active as far as I can see.

The 460.89 driver was installed by using NVcleanstall, which eliminates the need for manual inf modding:

https://www.techpowerup.com/download/techpowerup-nvcleanstall/

GM107_82.07.97.00.04.rom