zyzzle wrote on 2026-06-18, 09:13:

Falcosoft wrote on 2026-06-16, 04:31:

Hi, Actually this Intel integrated GFX dimming problem has nothing to do with 'gamma'. I t happens when a program switches on 8 […]
Show full quote

Hi,
Actually this Intel integrated GFX dimming problem has nothing to do with 'gamma'. I t happens when a program switches on 8-bit DAC through a VESA call FUNCTION 08H - SET/GET DAC PALETTE FORMAT. In case of Intel GFX if the program does not switch back to default 6-bit DAC when it exists then the dimming problem occurs.
Here you can download a small utility that does not change anything else just switches the DAC back to 6-bit (RESETDAC):
Re: NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)

Wow, thanks for making that utility and for the explanation. That solves the problem. (I had mentioned perf.exe before and it being a DOS program which suffers this problem). I saw also that Marco released a new version of NEWAX (v.11) as well, thanks. As far as I know, it is the only utility which "fools" a VBE 3 system with Intel onboard graphics in Sandy Bridge, Ivy, Broadwell, Skylake, Kaby Lake to act like a VESA2 system. This feature seems to work, even though I have to use /F option since this isn't an Nvidia chipset.

The other utility of mine (VSYNCFIX02) in that topic also "fools" a VBE 3 system with Intel onboard graphics in Sandy Bridge, Ivy, Haswell to act like a VESA2 system. Besides this it also fixes the missing v-sync is Vesa modes in case of Intel GFX (Sandy Bridge, Ivy Bridge, Haswell). But be aware that according to tests it does not work on Skylake+ since the architectural VGA port 3DAh does not behave as a standard VGA status register and thus the v-sync TSR cannot work (resulting in infinite loops).
Re: NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)

BinaryDemon wrote on 2026-06-18, 11:54:

Somehow I missed this thread previously, what an awesome utility. I suspect you could made some good money selling this to OEMs in the late 80/early 90s.

Thanks, I guess I am unfortunately a couple of decades too late.

Updated SANE to v2.30 which reinforces Dallas RTC stopping on ACPI operations.
Find the updated download archive on the first post of this thread.

igully wrote on 2026-06-17, 15:48:

Thank you!
This is extremely valuable information.

It turns out the scenario causing the APM system to become unresponsive is after using setmul to change the CPU multiplier or cache state, it seems to do something to the chipset which prevents SANE from running correctly

SetMul - Multiplier control for VIA C3 / AMD K6+7+8 Mobile / Cyrix 5x86

NeoG_ wrote on Today, 11:30:

It turns out the scenario causing the APM system to become unresponsive is after using setmul to change the CPU multiplier or cache state, it seems to do something to the chipset which prevents SANE from running correctly

SetMul - Multiplier control for VIA C3 / AMD K6+7+8 Mobile / Cyrix 5x86

I have the same effect when using Ali5Tht to slowdown for Ali5 based boards.
I'm not at home at the moment. But I think I remember pressing [ctrl]+[alt]+[del] for normally doing a warm reboot also has no effect after running Ali5Tht. So the issue seems not SANE related.

updated SANE to v2.32:

- Increased messaging verbosity.
- Reworked a few notification text messages.
- Reworked ACPITOOL

@crusher and @NeoG

Please retry this new version of SANE.

It seems both SetMul and ALi5Throttle manipulate power management to get things done. And a lot of things can potentially go wrong.
I am attaching a debug mode ACPITOOL to this post only. Just in case you need to dig in further (just replace the current one). In any case, all ACPI code management in SANE is externalized to ACPITOOL and the source code is there for anyone to take a peek. This is as far as I can go for the moment.