Just thought I'd write this down while I remember what I did...
My Samsung B2330H shipped with incorrect details in the EDID (eg max resolution given as 1280x1024 instead of 1920x1080, wrong screen dimensions). Samsung support were hopeless - they sent the monitor back unfixed and the techy I spoke to on the phone didn't seem to have even heard of EDID.
Rather than mess around with sending it back a second time, I decided to have a crack at fixing it myself.
EXTRA WARNING (thanks to packerfan for pointing out this should be right at the top!)
You are following these instructions at your own risk, while they worked for my setup they are not guaranteed to work for yours. Pay attention to the warnings i2ctools gives you as you can permanently break parts of your system by writing to the wrong location. By following this guide you agree to hold nobody liable for damages that may occur on your system (nor other effects caused by this guide) except yourself.
Don't mess about with this stuff without a really good reason, and don't blame me if your system gets permanently broken, your pet hamster dies, or anything else bad happens.
Step 1 - In Windows, I downloaded the free Phoenix EDID Designer, opened the faulty EDID from the registry and added some new correct Standard Timings as well as a new Detailed Timing in Descriptor block 1 for 1920x1080. I also changed the vendor ID and product ID from SAM0161 to SAM0649 as referenced in Samsung's supplied Windows driver (this turned out to be a little but non-fatal mistake). I used the unregistered version of Powerstrip to figure out the settings for the detailed timings, and generally plugged in all the information I could find in the monitor manual... I then printed out a copy of the output from Tools|Byte Viewer
Step 2 - The registered version of Powerstrip apparently has a facility to rewrite monitor EDIDs, but (a) the developers make clear that it's unsupported and not recommended; and (b) I'm a cheapskate, so I had a look for another way of doing this...
My PC dual-boots Fedora 13 Linux. This has a package of software called i2ctools which allow reading and writing over the I2C bus, which is what passes EDID data between the PC and the monitor.
Step 3 - Running as root in Fedora, I ran:
i2cdetect -l
to list all of the installed buses. I found three in total (0, 1 and 2).
Step 4 - Running:
i2cdetect 1
showed something at 0x50 which is where EDIDs live, so I ran:
i2cdump 1 0x50
and was rewarded with a printout of my monitor's current EDID for the DVI connector I'm using. EDIDs all start with header bytes 00 FF FF FF FF FF FF 00.
Step 5 - Now I needed to change the EDID to the revised version I had created in Phoenix EDID Designer. The EDID in Samsung monitors is write-protected, but people with other Samsung LCD models have found that this can be unlocked by showing the service menu, and this turns out to be true for the B2330H as well - go to menu; set contrast and brightness to 0; in the menu, hold the "input/enter" button until the red and white service menu appears.
Step 6 - I did this the slow way, one byte at a time...
i2cset -r 1 0x50 0x27 0xc0 (for example)
sets hex byte 27 of the monitor's EDID to its new value of hex c0. The -r reads back the value after it has been written, to check that it has changed successfully. I went through the EDID changing one byte at a time very carefully, although about half of the 128 bytes remained unchanged from the original EDID. When I was finished, I ran:
i2cdump 1 0x50
again and checked very carefully that everything matched the printout of my revised EDID from Phoenix.
Step 7 - turn monitor off and on again and reboot. Success as Windows XP booted straight into 1920x1080! Linux also booted to the correct native resolution without any more messing about manually setting modelines.
Step 8 - My near undoing... Because I had changed the monitor ID, Windows XP noticed and went looking for a driver for SAM0649. Unfortunately this turns out to be the correct EDID ID for the analogue side of the monitor, so Windows looked for the B2330H analogue driver, despite the fact that I was connected using DVI.
As I now realise, this doesn't matter, but being a perfectionist, I decided to try changing the monitor ID in the EDID to SAM064A, which is the correct code for the digital side.
Here I hit a stumbling block in Phoenix EDID Designer - although the tooltip for the Product ID field says "4 digit hexadecimal manufacturer product code", Phoenix would only let me enter numbers from one to ten. I thought I'd be cunning and pasted in "064A" from Notepad, which seemed to work, but changing the 2 altered digits in the monitor EDID left me with a black screen when the computer rebooted (maybe something out-of-range?). I can't figure out why this was, as the only 2 bytes I'd altered were Product ID and the EDID checksum (final byte).
I could get a low-res display by booting Windows XP in VGA mode (F8 during boot), and in Linux by adding 'nomodeset' as a kernel parameter at boot time, but unfortunately this has the side-effect of stopping i2ctools from accessing the EDID data (I think this will only work with certain display drivers in Linux).
At this point I was starting to panic - I couldn't even change things back blind in Linux, as Samsung have annoyingly made a monitor which won't display any menus unless it's displaying something on screen). Luckily, when I booted into Linux with both analogue and DVI cables connected, but the analogue input selected, I was able to see the EDID data again and revert the offending 2 bytes.
I hope this info is useful to anyone else hoping to write new EDID data to their monitor but BE WARNED!!! This worked for me with my particular setup (Radeon 9500 graphics card, Samsung B2330H monitor, Fedora 13 Linux) and I stumbled perilously close to messing things up permanently. You could very easily end up with a monitor that won't display a thing and that you are unable to fix. Only some monitors will have an EDID EEPROM which is rewritable at all. If you write to a wrong EEPROM on the i2C bus, you could even permanently kill other pieces of your system. Read the dire warnings i2ctools gives before you do anything!
Mark
|