Custom Resolution Utility (CRU)

[hannes69]

(Yesterday 06:01 AM)ToastyX Wrote:  The HDMI output shouldn't be able to corrupt the EDID. Did you unplug the projector's power or move it at any point? Maybe it was already corrupted for a while and cached in the projector's memory.

My projector has a permanent flashing blue power led when turned off, so after using the projector I pull the power plug... Once every day...
The projector got some 'treatment' from me several times (opening, cleaning, clean color wheel, new lamp, remove dust particels from DLP chip,...) and I have used a self made RS232 cable to access the service menu. Yes, maybe there got something wrong...
But interesting that it worked with my old PC but immediately not with my new PC.

(Yesterday 06:01 AM)ToastyX Wrote:  Are you able to read the EDID with EDWriter? If it's corrupted, it will offer to fix the data. Then you can try writing the EDID and hope it's not write protected

Didn't know that you have written a great tool beside CRU utility
EDWriter connected, read the data, offered a fix, applied the fix and finally could write to the EEPROM. Puh, lucky in this regard, no write protection I know from the inner parts of the projector, that the EDID chip is not directly accessible, so that would have meant another effort, doable but like always with this projector - effort.
After that everything went back to normal, the projector is recognized as HDMI and all resolutions are available
Many thanks for the link to another great tool made by you, helped me!
In the meantime I checked my old PC and found the EDID data of my projector in Windows registry. I compared the raw data with the new corrected data from EDWriter and used an online EDID decoder. Seems to me that the only difference I could detect was the checksum. The corrected EDID has a valid checksum and the old one on my old PC has an invalid checksum.
So my old PC maybe knew the working setting, then there was corruption and it still worked by ignoring the invalid checksum. But my new PC got the invalid checksum directly from the start and maybe didn't like that? How can a checksum be wrong while at the same time all data being correct, is this possible?

(Yesterday 06:01 AM)ToastyX Wrote:  DVI is always full range RGB. To get an HDMI signal, add a CTA-861 extension block and an HDMI data block.

Good to know, thanks.

Beside that: The whole video timings topic seems to be very complicated especially in HTPC and in combination with audio clocks.
In my new PC another strange thing is happening: After a fresh boot or reboot the refresh rate of a display is way off to the calculated one from pixel clock and horizontal/vertical totals. Both madVR and vsynctester.com report the same and totally off refresh rate. E.g. a perfect 100.00000 Hz refresh rate (for 25fps and 50fps movies) leads to 99.81 Hz. Not acceptable for a HTPC. But: systematically after sleep mode and wake up in Windows 10, the refresh rate is more or less like the calculated one. Simply found out by accident. Made my tests, nothing worked as intended, got away some time and PC was in sleep mode, came back, woke up PC and changed nothing, and magically everything OK. And now found out that it is systematically like that. So from a clean boot wrong things happen and from a sleep wake up (where many people have big problems) the right things happen... Strange world. Maybe it has something to do with clocks, but I have no clue what to do here. The Ryzen 8600g is my first iGPU, before I always had discrete GPUs. I don't trust the iGPU totally, the graphics outputs are part of the mainboard and the GPU is within the CPU, so maybe the clocks are spread and not 'unified' on one device like on a discrete GPU, who knows...