Problems with HD4000 and display settings

[rjstott]

I have just managed to get my new build working after a week of problems with only having 'safe' mode. I am running an Asus P8Z77-v PRO but without any graphics card. The processor is an Ivy Bridge 3570K and it overclocks nicely in Windows! Everything went smoothly except I tripped over the VGA restriction which I initially got round with an HDMI to VGA adapter. However, I could never get the machine to run in anything but 'safe' mode. As soon as I set GraphicsEnabled to Yes all was lost including 'safe' mode. I eventually decided it was a screen problem and puchased a new monitor (Asus V229HR) and I can now clearly see that there is some sort of mismatch between the screen and the output video from the DVI port. The screen does not show up in 'safe' mode (i.e. there is only a default monitor and a generic resolution of 1024x768). Pressing the 'option' key brought up the 'Detect Displays' button but clicking did nothing. This is Mountain Lion!

Here is the setting file:-

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EthernetBuiltIn</key>
<string>Yes</string>
<key>GenerateCStates</key>
<string>Yes</string>
<key>GeneratePStates</key>
<string>Yes</string>
<key>GraphicsMode</key>
<string>1280x1024x16</string>
<key>GraphicsEnabler</key>
<string>Yes</string>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>darkwake=0</string>
<key>Legacy Logo</key>
<string>Yes</string>
<key>Timeout</key>
<string>2</string>
<key>UseKernelCache</key>
<string>Yes</string>
</dict>
</plist>

This worked once and I jumped with joy. Now the screen is identified in Display Settings and the resolution is set at 1920x1080.

Incidentally Windows 7 has been working from another drive, fine, for the whole week and it immediately saw the new screen and changed its settings to match.

On a restart later this PM we were back to an out of synch display and now of course the backup I took is in the same mode. BUT on around the third restart (having checked out windows and the backup) it just worked again!!

Can anyone suggest what might be causing this behaviour. I do have 'SwitchResX' running and have had for a few days and perhaps there is a timing issue with its startup Deamon. I've read that scripting preferences isn't possible.

The amount of effort put in by people here is just tremendous and the wealth of data is invaluable but I can't find anyone who has a similar issue though I think some who reach the 'spinning' gear may suffer this issue. I am sure a Graphics card would have avoided this but the final use for the machine is an HTPC, so no real need for the expense.

So, if you have any suggestions pass them on as I'm sure this isn't cured yet.

 

[rjstott]

OK, I found an old thread about this problem and have now modified org.chameleon.Boot.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EthernetBuiltIn</key>
<string>Yes</string>
<key>GenerateCStates</key>
<string>Yes</string>
<key>GeneratePStates</key>
<string>Yes</string>
<key>Graphics Mode</key>
<string>1920x1080x32</string>
<key>GraphicsEnabler</key>
<string>Yes</string>
<key>device-properties</key>
<string>7f00000001000000010000007300000002000000 02 010c00d041030a000000000101060000027fff04002c000000 4100410050004c002c00690067002d0070006c006100740066 006f0072006d002d0069006400000008000000050062011400 00006800640061002d0067006600780000000d0000006f6e62 6f6172642d31</string>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>darkwake=0</string>
<key>Legacy Logo</key>
<string>Yes</string>
<key>Timeout</key>
<string>2</string>
<key>UseKernelCache</key>
<string>Yes</string>
</dict>
</plist>

This seems to have fixed it or least I can now boot twice in a row without a problem. If you spotted my error in "GraphicsMode" well done but that just meant I could adjust the amount of distortion. Anyway the "device-properties" string seems to be the key. Can't say I understand it and the threads I was reading were a bit indeterminate about what fixed it. This seems to work for me. How reliable this is time will tell.