![]() More confusingly, the second time around it appeared that my display was at 60Hz instead of 59Hz, so the relevant key had changed slightly. Confusingly, new entries are created under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video key when switching device/driver. This allowed me to make the change in the GUI again and observe the effect. For some reason CCC appears to still work and now displays the more modern driver version. Windows automatically went through another prolonged detection cycle and returned to the original, Microsoft-supplied driver. These are 0 with overscan fully off (to the right in the GUI) and increase by one for each increment of the slider to the left.įinally, I again uninstalled the display adapter driver from Device Manager (including deleting the driver). Process Monitor does not show the full data but a bit of experimentation and zooming in with RegEdit showed that the relevant bytes are in both DALR6 and GDOADJR6 - in the former at byte 37 (offset 0x24) and in the latter at byte 21 (offset 0x14). ![]() I believe the prefixes are the same paths resolved by the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video mentioned by steffen and others. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\video\0000\DAL_DFPOptions SUCCESS Type: REG_BINARY, Length: 4, Data: 18 00 00 00 I can't personally test this solution, but it appears that it worked for people on fairly recent drivers, so give it a shot: go to Tom's Hardware or I'll just re-post it here: I found a fix for the overscan issue I don't know what the equivalent is on Windows, or if you can even read/write the settings without using Catalyst. There is a way to directly tweak the underscan/overscan on Linux by modifying values in the "PCSDB" (Persistent Configuration Store Database). It also seems to be a fairly unique decision among graphics driver developers, as I can't reproduce the weirdness on a number of other non-AMD devices: Android tablets, Nvidia cards, and Intel on-chip graphics. I don't agree with the policy, but that's the way it is. ![]() So they are sticking to their guns on underscanning by default on HDMI to ensure that nobody gets stuck with a desktop that's too big for their screen (with UI elements hanging "off the screen"). The argument is that if the desktop is too large, then the user can't see where the Catalyst icon is or the start menu, and they therefore can't navigate the UI in order to make the appropriate change. The basic idea is that AMD would rather underscan some people whose HDMI displays don't overscan, and create too small of a picture (blank spaces around the picture), rather than not underscan and cause people whose displays always overscan (with no setting to change it and incorrect EDID information) to have the desktop display too large. I've had extensive discussion about the overscan/underscan dilemma with AMD developers who work on the Catalyst drivers. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |