[SOLVED] lm-sensors bricked my display?

mich41 · 2015-02-02 20:12:12

Your monitor cannot be in their database since this database is from 2006. Mine also isn't, but after few failures to read SOMETHING.xml ddccontrol prints a warning that not all functionality will be available, loads the generic VESA.xml and works with that.

However, I got exactly the same screen as you when I ran ddccontrol on another monitor which doesn't support DDC/CI. This suggest that your panel simply doesn't understand DDC/CI at all. But if poking i2c causes it to misbehave, it must be using some other i2c-based protocol instead. Maybe there are some proprieaty tools for Windows or something, I don't know.

9233 · 2015-02-02 21:28:41

So to sum it up:
While probing for sensors, lm-sensors apparently wrote some values to the Monitors EEPROM, which screwed up the gamma.
Since it's an EEPROM, tearing down the Notebook to completely disconnect the Monitor from any power source won't erase those values, right?
And are those values certainly stored in the LCD panel itself? Because the panel is a pretty poor TN one, so I was about to replace it with a nice IPS panel anyway.
If that's the case it wouldn't bother me that much.

mich41 · 2015-02-02 22:19:19

If you are sure that this happened during the scan of DPDDC-A and not something else then, with 99.9% certainity, yes. Unlike in VGA or HDMI, in DisplayPort the i2c controller is embedded (or possibly even emulated) in the monitor itself so it would be difficult (and crazy) to attach any other device to this internal i2c bus of the LCD. In fact, doing so would be quite crazy even if the i2c controller was in the GPU since the PCH already has other i2c controllers for non-video stuff (the ones supported by i2c-i801, which apparently weren't scanned due to ACPI conflict).

Last edited by mich41 (2015-02-02 22:21:41)

9233 · 2015-02-03 10:47:16

mich41 wrote:

If you are sure that this happened during the scan of DPDDC-A and not something else then, with 99.9% certainity, yes.

Is there a way to test that? Because I remember the screen flickering at some point while sensors detect was running amd after the flickering, the gamma weirdness happend.

mich41 · 2015-02-03 18:44:10

You had to type y between each i2c scan, are you sure you don't remember when the screen started misbehaving?

Anyway, this issue got me curious how modern LCD monitors work and after some reading I think I know what have happened. Blurred and grainy image seems consistent with Vcom miscalibration (what is Vcom). You can go here and see their inversion test patters, one of them will probably flicker heavily (much worse than on other LCDs), possibly even in red or some other color which isn't grey. Also, the dot-crawl pattern should make the "grains" you observe move like crazy.

I found out that there are chips (e.g. MAX17106) which integrate several LCD controller components, including Vcom generators, EDID EEPROM and Vcom callibration data EEPROM. Curiously, in case of MAX17106, the Vcom EEPROM is found at address 0x4f (looks familiar?) on the same i2c bus as EDID so it seems that this was the poor victim of sensors-detect.

If this is true, LCD replacement will fix it. To fix the LCD itself, one would need to recalibrate it by eye on these test patterns.

Last edited by mich41 (2015-02-03 19:27:03)

brix · 2015-02-03 19:13:08

Though what the lm-sensors wiki page currently advises re the 'sensors-detect' command is scarcely a rock-solid guarantee,

The "safe" answers are the defaults, so just hitting Enter to all the questions will generally not cause any problems.

maybe it should include an explicit warning of the risk in probing laptop displays. I'd add it myself were I more confident of understanding the problem.
.

mich41 · 2015-02-03 19:36:38

Actually, isn't it completely useless on x86 laptops? In these I've seen, power management is exclusively done by the embedded controller and exposed either read-only via ACPI or not at all. And sensors-detect isn't needed to find ACPI thermal zones or coretemp.

Few years ago one could at least hack the FSB clock generator, now even this is locked (at least on Intel).

Last edited by mich41 (2015-02-03 19:37:39)

9233 · 2015-02-03 23:59:05

mich41 wrote:

You had to type y between each i2c scan, are you sure you don't remember when the screen started misbehaving?

Yes I had to type y each time, but the actual probing happened after all the questions and was way to fast to notice which exact line caused the problem.

mich41 wrote:

Anyway, this issue got me curious how modern LCD monitors work and after some reading I think I know what have happened. Blurred and grainy image seems consistent with Vcom miscalibration (what is Vcom). You can go here and see their inversion test patters, one of them will probably flicker heavily (much worse than on other LCDs), possibly even in red or some other color which isn't grey. Also, the dot-crawl pattern should make the "grains" you observe move like crazy.
I found out that there are chips (e.g. MAX17106) which integrate several LCD controller components, including Vcom generators, EDID EEPROM and Vcom callibration data EEPROM. Curiously, in case of MAX17106, the Vcom EEPROM is found at address 0x4f (looks familiar?) on the same i2c bus as EDID so it seems that this was the poor victim of sensors-detect.
If this is true, LCD replacement will fix it. To fix the LCD itself, one would need to recalibrate it by eye on these test patterns.

You did some great research, thank you!
So if we now at which address the specific EEPROM is located, I could try reprogram it.
I found a some Windows software like this one (I2C Bus Analyzer), which is able to read and write values via the i2c bus at a specific address. I guess this might be worth a try, right?

brix wrote:

maybe it should include an explicit warning of the risk in probing laptop displays. I'd add it myself were I more confident of understanding the problem.

Yes that would be great. Claiming that something is safe without specifying the risks off the unsafe options , isn't a good warning
I didn't even knew that the unsafe probes could persistently harm some Hardware components.

mich41 wrote:

Actually, isn't it completely useless on x86 laptops?

I was looking for some utility that could display the current CPU voltages and I saw some people doing this via lm-sensors.
However, on my machine it didn't so i thought it might be necessary to run sensors-detect first.

mich41 · 2015-02-04 12:31:22

The product you linked is a bus analyzer, i.e. a USB dongle which you connect to the bus so that the PC can monitor ongoing communications or send its own. But in this case you only need i2c-tools, which can employ the same eDP i2c interface that sensors-detect did.

We still aren't 100% sure if this is a MAX17106, but...

... if I understand the MAX17106 datasheet correctly, Vcom calibration data is only one byte in size. Adjustment is simple - any byte sent to 0x4f will be remembered as new Vcom calibration value and any request to receive from 0x4f will be answered with the current Vcom calibration value. This causes trouble with sensors-detect, because sensors-detect determines sensor's model by sending some command byte to it and seeing what answer it gets, while this dumb chip simply writes the received command byte to its memory. Ugh.

You said you want to buy a new panel anyway, right?

Run i2cdetect -l (this is safe) to see if bus numbers haven't changed on reboot. We are interested in the eDP DDC, which last time was bus number 6, called DPDDC-A. Say the current bus number is 1234.

Run i2cget -y 1234 0x4f. This sends no data bytes to the chip, only a single receive request, and waits for data. MAX17106 or compatible chip will answer with the current Vcom value. Some chips are said to lock up until you power cycle them, waiting forever for some command byte that never comes, but I don't think any chip is going to get permanently damaged by such read request. Although please don't quote me on that...

If this command always returns the same number, you likely have a MAX17106 or something similar and we can try to reprogram it the same way sensors-detect did.

Last edited by mich41 (2015-02-04 20:51:13)

9233 · 2015-02-07 20:15:11

Sorry for not replying for a long time, I had a lot to do for school.

mich41 wrote:

You said you want to buy a new panel anyway, right?

I guess it might be wise to wait until my new screen arrives, before risking to brick it more than it already had been
Unfortunately shipping takes 4 to 6 weeks, so we won't be able to do much for a while.

Last edited by 9233 (2015-02-07 20:15:47)

mich41 · 2015-02-07 23:22:42

Sure, might be wise if you actually use need this laptop

In case I won't be around when you decide to play with this stuff: i2cset -y 1234 0x4f n writes n (0-255) to the chip. You'll need to find some n that works

Note that if you have a MAX17106, then even numbers will be remembered permanently and odd numbers will be rounded down to even and then applied temporarily (until reboot). So it would be only 128 values to choose from

Last edited by mich41 (2015-02-07 23:23:43)

9233 · 2015-03-12 10:58:16

Hi guys!
I have finally received my replacement screen and everything looks fine again.
So the fact that sensors detect messed up with the EEPROM of the display panel is now 100 percent confirmed.

mich41 wrote:

S i2cset -y 1234 0x4f n writes n (0-255) to the chip.

Unfortunately this diidn't seem to make any difference at all. My old panel probably uses a controller other than the MAX17106.

At this point I'd like to thank all of you for helping me out with this problem!
Although we didn't exactly solve it, we have definitely learned something.
And since i was going to change the panel anyway i don't regret anything

Have a nice day!

mich41 · 2015-03-12 11:25:31

Are you sure you replaced 1234 with proper bus number?

I'm surprised this makes no difference, it's pretty much the same thing sensors-detect did.

Eh, whatever. Hardware is evil

9233 · 2015-03-13 19:47:39

mich41 wrote:

Are you sure you replaced 1234 with proper bus number?
I'm surprised this makes no difference, it's pretty much the same thing sensors-detect did.
Eh, whatever. Hardware is evil

Yeah sure, the bus number stayed the same (6) and I tried dozens of values with no success.
But if sensors-detect did the same, that's pretty strange indeed.

Rik123 · 2015-04-11 18:56:30

i2cset -y 6 0x4f 175
*

fixed it for me.

Had the same problem(see my next post)

*i cant be held responsible for any damages

Last edited by Rik123 (2015-04-12 07:02:45)

9233 · 2015-04-11 19:50:21

Rik123 wrote:

i2cset -y 6 0x4f 175

fixed it for me.
Had the same problem

Damn, now I want to try this again!
But I have no clue why it didn't work last time.
Maybe there are only a few values which do work.
I'm going to report back

Last edited by 9233 (2015-04-11 19:56:11)

Rik123 · 2015-04-12 07:14:18

I had the same problem on my lenovo z50. after using lm-sensors (followed a tutorial for seeing my pc temp) there was a flash and then the display was messed up like described here. i tried a lot of things and using i2c-tools fixed it.

First i looked what value i2cget -y 6 0x4f (n) returned, and the play with the n, trying different setting (n=3,155,255,..) and noticed the screen changed a bit. then i looked for the optimal n(=175) which makes thing normal again.(ps thank you mich41 for this command)

but it wasn't persistent so i looked for a command to make it persistent (the trick with n -even did not work) and found i2cset. now my screen is normal once again.

I would like to thank you all this forum helped me a lot

I wish you good luck 9233 and hope this fixes it for you.

*i cannot be held responsible for any damages a command above has done.

Last edited by Rik123 (2015-04-12 07:15:34)

9233 · 2015-04-16 14:53:36

So I finally had the time to try it again and it worked!
But it was really wired, I had to run the command a couple of times before it actually worked.
And only a few values made a difference, for example 175 didn't whereas 177 did and seemed to be optimal.
I'm glad we finally fixed the problem and hope we can help other people too.
Thank you all for contributing!

mich41 · 2015-04-16 17:55:00

Maybe the bit order is backward? Does adding or subtracting 128 or 64 make significant difference?

dragon21 · 2015-05-25 17:54:10

I have lenovo y50-70 and I need do that every time I reboot for fix my display someone help me please (sorry my bad english)

9233 · 2015-05-25 18:01:55

dragon21 wrote:

I have lenovo y50-70 and I need do that every time I reboot for fix my display someone help me please (sorry my bad english)

Try it with a even number (176 for example) instead of 175.
As mich41 stated, even numbers persist whereas odd numbers only fix it temporarily.

As Lenovo ships the Y50 with different display panels the optimal value for you could be different.

ferrettinico · 2015-08-31 21:33:38

I had this very same issue with my ASUS G551JW running Ubuntu 15.04 Running "sudo i2cget -y 6 0x4f 175" fixed it for me. If you get a READ ERROR from i2cget you have to turn off the computer, remove the battery, put the battery back and start the computer again

THANK YOU GUYS! I was freaking out

jaruj9 · 2015-11-03 19:16:32

9233 wrote:

dragon21 wrote:
I have lenovo y50-70 and I need do that every time I reboot for fix my display someone help me please (sorry my bad english)
Try it with a even number (176 for example) instead of 175.
As mich41 stated, even numbers persist whereas odd numbers only fix it temporarily.
As Lenovo ships the Y50 with different display panels the optimal value for you could be different.

Hi please, I have lenovo y50 as well. It happened to me exactly the same but when I run command sudo i2cget -y 6 0x4f 175 i get:
Error: Could not open file `/dev/i2c-6' or `/dev/i2c/6': No such file or directory

and when I run ln /dev/ it really is not there!

But every time I run again sensors-detect (and choose yes everywhere) the screen flickers. It means it connects somehow to i2c-6 I just dont know how.

PLEASE SOME HELP!

THANK YOU

Last edited by jaruj9 (2015-11-03 19:21:24)

9233 · 2015-11-03 19:24:24

jaruj9 wrote:

Hi please, I have lenovo y50 as well. It happened to me exactly the same but when I run command sudo i2cget -y 6 0x4f 175 i get:
Error: Could not open file `/dev/i2c-6' or `/dev/i2c/6': No such file or directory
and when I run ln /dev/ it really is not there!
But every time I run again sensors-detect (and choose yes everywhere) the screen flickers. It means it connects somehow to i2c-6 I just dont know how.
PLEASE SOME HELP!
THANK YOU

After installing the i2c-tools package you have to load the eeprom kernel module:

# modprobe eeprom

jaruj9 · 2015-11-03 19:29:44

9233 wrote:

jaruj9 wrote:
Hi please, I have lenovo y50 as well. It happened to me exactly the same but when I run command sudo i2cget -y 6 0x4f 175 i get:
Error: Could not open file `/dev/i2c-6' or `/dev/i2c/6': No such file or directory
and when I run ln /dev/ it really is not there!
But every time I run again sensors-detect (and choose yes everywhere) the screen flickers. It means it connects somehow to i2c-6 I just dont know how.
PLEASE SOME HELP!
THANK YOU
After installing the i2c-tools package you have to load the eeprom kernel module:
# modprobe eeprom

Thank you very very much for your fast response! I have done it, run command sudo i2cget -y 6 0x4f 175 but I still get the same error. lsmod shows that module is loaded.

sudo i2cdetect -l

gives no result.

Do I have to open the computer and reinsert Battery? As u know is not accessible from outside.

I am looking forward for any further help thank you again!!!!

Last edited by jaruj9 (2015-11-03 19:35:21)

Arch Linux

#26 2015-02-02 20:12:12

Re: [SOLVED] lm-sensors bricked my display?

#27 2015-02-02 21:28:41

Re: [SOLVED] lm-sensors bricked my display?

#28 2015-02-02 22:19:19

Re: [SOLVED] lm-sensors bricked my display?

#29 2015-02-03 10:47:16

Re: [SOLVED] lm-sensors bricked my display?

#30 2015-02-03 18:44:10

Re: [SOLVED] lm-sensors bricked my display?

#31 2015-02-03 19:13:08

Re: [SOLVED] lm-sensors bricked my display?

#32 2015-02-03 19:36:38

Re: [SOLVED] lm-sensors bricked my display?

#33 2015-02-03 23:59:05

Re: [SOLVED] lm-sensors bricked my display?

#34 2015-02-04 12:31:22

Re: [SOLVED] lm-sensors bricked my display?

#35 2015-02-07 20:15:11

Re: [SOLVED] lm-sensors bricked my display?

#36 2015-02-07 23:22:42

Re: [SOLVED] lm-sensors bricked my display?

#37 2015-03-12 10:58:16

Re: [SOLVED] lm-sensors bricked my display?

#38 2015-03-12 11:25:31

Re: [SOLVED] lm-sensors bricked my display?

#39 2015-03-13 19:47:39

Re: [SOLVED] lm-sensors bricked my display?

#40 2015-04-11 18:56:30

Re: [SOLVED] lm-sensors bricked my display?

#41 2015-04-11 19:50:21

Re: [SOLVED] lm-sensors bricked my display?

#42 2015-04-12 07:14:18

Re: [SOLVED] lm-sensors bricked my display?

#43 2015-04-16 14:53:36

Re: [SOLVED] lm-sensors bricked my display?

#44 2015-04-16 17:55:00

Re: [SOLVED] lm-sensors bricked my display?

#45 2015-05-25 17:54:10

Re: [SOLVED] lm-sensors bricked my display?

#46 2015-05-25 18:01:55

Re: [SOLVED] lm-sensors bricked my display?

#47 2015-08-31 21:33:38

Re: [SOLVED] lm-sensors bricked my display?

#48 2015-11-03 19:16:32

Re: [SOLVED] lm-sensors bricked my display?

#49 2015-11-03 19:24:24

Re: [SOLVED] lm-sensors bricked my display?

#50 2015-11-03 19:29:44

Re: [SOLVED] lm-sensors bricked my display?

Board footer