Hi Numan, Sorry for the late reply, I have a lot of work this week. On Tue, 3 Apr 2012 21:33:58 +0300, Numan DEMİRDÖĞEN wrote: > > * Did you leave the default answer to every question, or did you ask > > for probing which was disabled by default? > > I answered all questions to yes. I presume you do not remember which ones defaulted to "no" and you had to say "yes" explicitly? > > I see you're using the radeon driver on a RV380 chip. Do I understand > > correctly that this is a laptop and the screen you're talking about is > > the laptop's own screen? Fujitsu-Siemens Amilo Pro V2045, right? > > Yes, it is a laptop and I am talking about it's screen. It is a > Fujitsu-Siemens Amilo Pro V2045. > > > It would be great if you could dig your logs for a dump of your EDID _before_ the corruption. The radeon driver logs this > > to /var/log/Xorg.0.log. If you can't find that, it would be great to find another user with the same laptop who could provide > this dump. > > Unfortunately, there is no dump of EDID in the Xorg.0.log. It's strange, I do see it in mine with the radeon driver: [ 7.942] (II) RADEON(0): EDID for output DVI-0 (...) [ 7.943] (II) RADEON(0): EDID (in hex): [ 7.943] (II) RADEON(0): 00ffffffffffff001e6d7d58c3750600 [ 7.943] (II) RADEON(0): 0915010380331d78ea5ea5a2554da026 [ 7.943] (II) RADEON(0): 115054a76b80b30081808140714f0101 [ 7.943] (II) RADEON(0): 010101010101023a801871382d40582c [ 7.943] (II) RADEON(0): 4500fe221100001e000000fd00384b1e [ 7.943] (II) RADEON(0): 530f000a202020202020000000fc0049 [ 7.943] (II) RADEON(0): 50533233350a202020202020000000ff [ 7.943] (II) RADEON(0): 003130394d41464343463336330a008c Maybe there is a verbosity level to set somewhere, my X server is started with -verbose, maybe you have to do the same. Or > My screen is a SAMSUNG LTN 154X3-L01. > Here is the Xorg.0.log output: http://pastebin.com/7Y2wRWpg > But, fortunately, I found some dump of EDID: http://pastebin.com/HDTG4T2W > There are 3 more of like this and they belong to same monitor, SAMSUNG > LTN 154X3-L01. They have same manufacturer, model, EDID version and > product year. All of this dump of EDID are exactly same. Good, so at least we have a reference. Now we need to find out which bytes in your own EDID have been altered. > > First run xrandr --verbose to have the detailed timings for 1280x1023, and then use --newmode with 1023 replaced by > > 800 > I took your advice and gave xrandr --newmode "try" 68.9 1280 1296 1544 > 1408 800 1024 1027 1039 command ( replaced 1023 with 800) Now, it is > better. I mean before this command, I could not see the bottom of > applications if I used them maximized but now I can see a little bit > of bottom of applications. 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 > > I'd be more interested in the output of i2cdetect for each but for now. Also I'm not sure what you were trying to achieve >with: > > I thought i2cdump output would be usefull so I added them. > I loaded i2c-dev, eeprom and radeonfb modules than gave i2cdetect, > here is the output: http://pastebin.com/4fK1Y4P9 > > > I suspect you meant 0x50, not 0x60. Please try that and report. I would also need the (bogus) EDID dump from /var/log > > /Xorg.0.log. > > Sorry, here is the result that you wanted: > > sudo i2cdump 2 0x50 > No size specified (using byte-data access) > Error: Could not set address to 0x50: Device or resource busy 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. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
