On Fri, 6 Apr 2012 11:28:58 +0300, Numan DEMİRDÖĞEN wrote: > 2012/4/6 Jean Delvare <khali@xxxxxxxxxxxx>: > > It's strange, I do see it in mine with the radeon driver: > > Maybe there is a verbosity level to set somewhere, my X server is > > started with -verbose, maybe you have to do the same. Or > > I stopped X and gave "exec /usr/bin/X -nolisten tcp "$@" -verbose 20 > 2> /tmp/startx.log" command but still there is no dump of EDID. Maybe this is because the EDID is corrupted and thus the checksum is incorrect. > > Good, so at least we have a reference. Now we need to find out which > > bytes in your own EDID have been altered. > > You also have to offset the 3 other vertical timings: > > $ xrandr --newmode "try" 68.94 1280 1296 1344 1408 800 801 804 816 -HSync -VSync > > Now I get what you wanted me to do. I tried the command above but > resolution looks bad. Icons, fonts etc. looks blur and bigger. Very odd, given that this is the exact modeline computed from the original EDID. > > That's because you have loaded the eeprom driver. Either provide the > > contents of file /sys/bus/i2c/devices/i2c-2/2-0050/eeprom or unload the > > eeprom driver and provide the output of the i2cdump command above. > > Sorry, my mistake. This is the output: http://pastebin.com/aSUSR7wX Note the XX in the dump, which means an error occurred on the bus. Please check your kernel logs to see if there is an error message corresponding to this failure. If the I2C bus is unreliable, this could explain in part the trouble you had. Comparing the original EDID with your tampered copy shows 6 bytes that are now 0xff instead of the value they used to hold: 0x2b: 0x01 -> 0xff 0x2e: 0x01 -> 0xff 0x2f: 0x01 -> 0xff 0x3b: 0x20 -> 0xff 0x3f: 0x30 -> 0xff 0x78: 0x33 -> 0xff FWIW, this doesn't correspond to a specific pattern for sensors-detect, which accesses the following offsets for probing this specific address: 0x00-0x07 and 0x3d-0x3f. So I still have no idea what happened and why. Assuming your EDID EEPROM is writable, the following commands (as root) should restore its original state: # rmmod eeprom # i2cset -y 2 0x50 0x2b 0x01 b # i2cset -y 2 0x50 0x2e 0x01 b # i2cset -y 2 0x50 0x2f 0x01 b # i2cset -y 2 0x50 0x3b 0x20 b # i2cset -y 2 0x50 0x3f 0x30 b # i2cset -y 2 0x50 0x78 0x33 b You can check with i2cdump afterward. I'd even check after fixing the first byte, as there is no point in going on if the first write failed Let's hope it does the trick... -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
