***EVGA Precision X and Windows 7/8/8.1 and especially 10 bricking systems***

Managed to fix my issues with a fresh Ubuntu USB stick and a lot of patience. Had to install all the repos and packages manually tot het i2ctools tot work, but now everything works. Used the EDID from this thread!


So here are my steps:

- First made a Ubuntu live usb stick using Rufus
- Had to set boot mode to non-uefi (legacy) in the bios to be able to boot
- got a black screen in Ubuntu as well, has to use a secondary monitor to flash the internal display

First had to add these repos (main and restricted were already installed):

sudo add-apt-repository main
sudo add-apt-repository universe
sudo add-apt-repository restricted
sudo add-apt-repository multiverse

Sudo apt-get update

sudo apt-get install -y i2c-tools

Next I could follow the instructions in this topic, but had to make a small change to the write-edid.sh from GitHub ( https://github.com/tomka/write-edid) , as it did not run for me. Got an error somewhere at line 72.


Had to change a small piece of the code from GetOneLine to ”read line". See here: https://github.com/ChalkElec/write-edid/issues/1

 

Awesome. Nice job! Better than wasting money replacing a perfectly good LCD panel.

Interesting that the Clevo P650HP6-G got the display bricked.

 

The odd thing is I found 2 locations (i2c-10 and i2c-15) that were exactly the same and corrupted. Both were for my display. Any idea how this is possible?

Verstuurd vanaf mijn GM1913 met Tapatalk

 

Mr. FOX could you send me a message? I can't seem to find a way to send you one... I just want to pick your brain here.... Thanks

 

Mr Fox et al.

I have just stumbled upon your previous thread from 2015 regarding W10 destroying M18 screens.

I have an M18xR2 with dual 675m cards purchased in the UK in August 2012. The machine was shipped with Win 7 Pro and has been upgraded to Win 10.

For the last year I have been running into issues with my screen going black and the "found new hardware "chime playing.

My primary suspicion is failing cards, but I really hope not as I cannot afford to replace them. Can you recommend a stable driver to try? I tried the Dell/AW driver for Win 8.1 (339.xx) not sure if there is a better one?

I have heard that nVidia just supplies chips to the major manufacturers and running drivers direct from nVidia may not work properly, but since Dell/AW do jot officially support W10 on my machine I am at a loss.

 

It could very well be the GPU(s). Probably only the master GPU and it is unlikely both of be failing simultaneously. If you're do for another thermal paste application, try swapping slots with the GPUs and then disable SLI and see if that problem continues.

What driver are you using now? You can try using the latest driver with NVCleanstall to add support for the hardware ID.

 

Thank you for the speedy response Mr Fox.

nVidia website lists 389.xx as the most up to date driver (2018 I think) for my cards.

Dell only gives me 339.xx since they do not offer support for Windows 10.

Interestingly the highest driver that driverscape.com offers for my machine is 353.62 (which I did not use having read your previous warnings) instead I downloaded the 347.52 offering that they had and will see how it goes.

I have never reapplied thermal past in the 8 years I have owned the machine. And have not used it for the intense gaming I imagined when I bought it back in 2012.

I am comfortable taking the machine apart, but will have to order paste as I live remotely. How much will I need and what is a good (but also affordable) thermal paste to pick?

 

You download the lastest GPU driver from the official Nvidia website.

 

If the card is now of main line support then later drivers than the ones the Nvidia site recommend wont help.

 

Hi hello. I created an account just so I could post this.
I own a P650HS-G with a gtx 1070 and I have the same problem that user Agil1ty had namely that:
I cannot update driver past the one provided by Clevo, else my screen would freeze.
Installing intel gpu driver gets me a black screen.
Here's my gpu-z and device manager screenshots.



I am not at all familiar with tech nor programming, but I can follow instructions. If username Agil1ty or someone else who understood what he did, could walk me through what he had done to fix his issue, I would appreciate it very much. Private message if necessary, so I wouldn't clutter this thread with dumb basic questions.

Thank you so much.

 

Hi tehwatever,

The top message I have quoted from "t456" with the "Live and persistent Linux with edid tools" is what you need to fix your edid issue, I too followed his instructions to fix the same issue.

 

Hi John. Thx for the reply. I'm still not quite sure how to proceed. Here's what I got so far.
-Written the Linux image with Rufus onto a USB stick.
-disabled UEFI boot in BIOS
-Successfully booted into the Linux Desktop without installing (Try without Installing)

-opened 'pnp id -panel nrs.txt'

-saw a couple of pnp ids and their corresponding bin files, and some notes on the bottom of the text.

I dont know how to proceed. Which bin file do I pick?
Thanks again and sorry for being so clueless.

 

So anyway I am using the LP156W6-SP (B1), whose correct edid has not been updated in the link above.
I also run into this problem:

when I did this in the terminal
root@lubuntu: ~# sudo sensors-detect

it gave me a prompt and I hit 'n' for all the prompts until

Do you want to probe the I2C/SMBus adapters now? (YES/no): y
Found unknown SMBus adapter 8086:a123 at 0000:00:1f.4.
Sorry, no supported PCI bus adapters found.

Sorry, no sensors were detected
I'm sorry that I'm illiterate. I'm also sorry for bumping an inactive thread but I have nowhere else to turn at the moment, and I know at least one more person plagued with similar problem.

Thank you guys, in advance.

 

Hi this stuff is really hard to get in to and it took me weeks to fix. Somehow your edid in your monitor got busted. You could also choose to replace the monitor (opening your laptop and replacing the screen). If you don't see the PCI bus, make sure that in the bios discrete graphics are on.

You can follow the steps I did in my other post:

So here are my steps:

- First made a Ubuntu live usb stick using Rufus
- Had to set boot mode to non-uefi (legacy) in the bios to be able to boot
- got a black screen in Ubuntu as well, has to use a secondary monitor to flash the internal display

First had to add these repos (main and restricted were already installed):

sudo add-apt-repository main
sudo add-apt-repository universe
sudo add-apt-repository restricted
sudo add-apt-repository multiverse

Sudo apt-get update

sudo apt-get install -y i2c-tools

Next I could follow the instructions in this topic, but had to make a small change to the write-edid.sh from GitHub ( https://github.com/tomka/write-edid) , as it did not run for me. Got an error somewhere at line 72.


Had to change a small piece of the code from GetOneLine to ”read line". See here: https://github.com/ChalkElec/write-edid/issues/1

 

Hope this helps mate. As I said, you can also opt to replace the entire LCD.

 

Hi Agil1ty. Thanks for the reply. I'm not on my laptop atm and probably can only get to it in 5 hours or so, but I made sure my laptoo was on discreet graphics, since MSHYBRID just gives me black screen. Anyway last night I tried to follow your instructions but due to my illiteracy I have no idea what you meant in each step.

1. Ubuntu live USB stick using Rufus. Which image? Any Ubuntu image or the one by user t456?
2. Set boot to non-UEFI (legacy). How do that? I can disable UEFI in bios, if that is what you mean.
3. Use 2ndary monitor to flash internal display. What is 'to flash' and how?

For now let's start with them, just so I understand a little better.

Thanks again.

 

First of all I have this screen:

LP156WF6SPBQ (LG D046F), and used the EDID from this thread. The file I sent you is also for this specific screen.

Make the bootable Ubuntu stick
Hi, any ubuntu live iso image will do, just grab the latest one and make a bootable USB drive with Rufus



You should disable UEFI in BIOS, and enable MShybrid (not discrete graphics, my bad) . I know you will get a black screen, so you need a secondary monitor to do this (or a tv with hdmi connection), as it will also show a black screen in ubuntu (but I dont think it freezes).

Boot into ubuntu with the live USB stick
You are gonna flash the internal memory of the monitor (or EDID), with specific tools in ubuntu. You need to install these first:

Open terminal
type

sudo su (this will give you administrator rights)

type to install repositories (one line at a time)
sudo add-apt-repository main
sudo add-apt-repository universe
sudo add-apt-repository restricted
sudo add-apt-repository multiverse

This will install repositories, you can see this as install locations where you can get specific tools from.

Next, update the repositories:
Sudo apt-get update

Next, you are gonna install i2c-tools to check the I2C/SMBus, and to check which is faulty

sudo apt-get install -y i2c-tools

Now i had to make some modifications to the write-EDID.sh (this is a script that will install the proper EDID). I have added these modified bash scripts in the attachement.


Next, i could follow these instructions:

01 check 'pnp id -panel nrs.txt' for the correct bin (in the 'archive' folder)

02 copy it to the 'write-edid' folder (the one in the archive is for the LP156WF6SPBQ (== LG D046F))

03 open terminal (ctr+alt+T)

04 sudo bash

05 sudo sensors-detect

Hit 'n' for all 'YES/no' questions, EXCEPT I2C/SMBus, hit 'y' for that.

There'll be something like 'Using driver 'i2c-XYZ' <- mine was i2c-i801 (Lynx Point),
hit 'n' for the remaining questions.

06 sudo modprobe i2c-XYZ (i2c-i801 for me)

07 sudo modprobe i2c-dev

08 sudo i2cdetect -l

result:
######################################
root@it:~# sudo i2cdetect -l
i2c-0 i2c i915 gmbus ssc I2C adapter
i2c-1 i2c i915 gmbus vga I2C adapter
i2c-2 i2c i915 gmbus panel I2C adapter
i2c-3 i2c i915 gmbus dpc I2C adapter
i2c-4 i2c i915 gmbus dpb I2C adapter
i2c-5 i2c i915 gmbus dpd I2C adapter
i2c-6 i2c DPDDC-A I2C adapter
i2c-7 i2c DPDDC-C I2C adapter
i2c-8 i2c nouveau-0000:01:00.0-0 I2C adapter
i2c-9 i2c nouveau-0000:01:00.0-1 I2C adapter
i2c-10 i2c nouveau-0000:01:00.0-2 I2C adapter
i2c-11 i2c nouveau-0000:01:00.0-5 I2C adapter
i2c-12 i2c nouveau-0000:01:00.0-6 I2C adapter
i2c-13 i2c nouveau-0000:01:00.0-7 I2C adapter
i2c-14 i2c nouveau-0000:01:00.0-8 I2C adapter
i2c-15 i2c nouveau-0000:01:00.0-9 I2C adapter
i2c-16 i2c nouveau-0000:01:00.0-26 I2C adapter
i2c-17 i2c nouveau-0000:01:00.0-27 I2C adapter
i2c-18 i2c nouveau-0000:01:00.0-28 I2C adapter
i2c-19 i2c nouveau-0000:01:00.0-29 I2C adapter
root@it:~#
######################################

If, for whatever reason, you have restarted/rebooted AFTER running 'i2cdetect -l';
ALWAYS RE-RUN THAT COMMAND before asssuming the edid will be on the same bus.

The bus enumeration is usually fixed, but not always so; make CERTAIN you have the right bus.

Those 0-19 are the list of buses, now we need to find out which bus the panel is on.
It could be 'panel' (bus 2), but one the 'DPDDC's is also possible.
Let's try bus 2 first. we read (-r) the bytes 0 to 127, so 128 bytes in total, and
we check this bus 2 at address 50 <- this SHOULD contain the edid, BUT-T-T-T ...
that is not guaranteed -> IF it is on a different address then either the read part
or, especially, the writing part can change things that are hard to fix.

We're not interested in the difference between 128 byte or 256 byte edids yet,
so extracting the first 128 bytes will do for now.

09 sudo i2cdump -r 0-127 2 0x50

result:
######################################
root@it:~# sudo i2cdump -r 0-127 2 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2, address 0x50, mode byte
Probe range limited to 0x00-0x7f.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
root@it:~#
######################################

So the edid is not here. If it was the edid then you'll see the
'00 FF FF FF FF FF FF 00' start header, even if a little corrupted.
If you find that then you know the bus AND the address.
Anyway, let's try bus 6 next (DPDDC-A).

09 sudo i2cdump -r 0-127 6 0x50

result:
######################################
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4d 10 ff 13 00 00 00 00 ........M?.?....
10: 00 17 01 04 a5 1d 11 78 06 de 50 a3 54 4c 99 26 .??????x??P?TL?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 ?PT...??????????
30: 01 01 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20 ??????V^.???)P0
40: 35 00 26 a5 10 00 00 18 00 00 00 10 00 00 00 00 5.&??..?...?....
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 .............?..
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc ...............?
70: 00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20 00 b0 .LQ133T1JW02? .?
######################################

Good, bus 6 it is. Now pay attention to byte 7e. Read address
like it was excel: ROW-COLUMN. In this example 7e = 00 (zero) and
it's in-between values 20 and b0.
The b0 is the final byte (and checksum), if 7e = 01 (one)
then you have an extension block and require a 256 byte edid.
These are also availeable in the archive, but the difference is that
you need to use 'write-edid-256.sh' instead of 'write-edid.sh'.

Let's make an export to verify actual corruption first and
also to help further research:

09 sudo i2cdump -r 0-127 6 0x50 > EDID/edidexport.txt

Or, if case you have a 256 byte edid:

09 sudo i2cdump -r 0-255 6 0x50 > EDID/edidexport.txt

Check the export by opening the .txt and copy/pasting the
significant hex values to the Web Based EDID Reader website.
The pasted values should be stripped of row and column id
and the ascii characters to the right:

example:
######################################
00 ff ff ff ff ff ff 00 4d 10 ff 13 00 00 00 00
00 17 01 04 a5 1d 11 78 06 de 50 a3 54 4c 99 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20
35 00 26 a5 10 00 00 18 00 00 00 10 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20 00 b0
######################################

If the EDID Reader says 'checksum valid' then do not proceed
any further; the edid is fine and, thus, something else must be wrong ...

If it says 'checksum fail' AND you have your bus AND address by now;
skip the stuff below and proceed to step 10.

If, on the other hand, you received all XX on all buses then 50 is not
the right address for you ... we need to look beyond 50:

09 sudo i2cdetect 6

result:
######################################
root@it:~# sudo i2cdetect 6
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-6.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- 11 -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@it:~#
######################################

So there IS something else here besides the edid at 50 ...
Wonder what that button does ...
Anyway; go back to the beginning of step 9 and redo the 'read bus',
only this time at address 11 (or whatever your results were).

######################################

10 cd EDID/edid-rw

At this point we should have:
- BUS (here 6)
- ADDRESS (here 50)
- EDID LENGTH 128 or 256 (here 128).

11 sudo ./edid-rw 6 | edid-decode

This is just a precaution; we want to make sure edid-rw uses the
right address, if not then we need to change its code (report this if so).

result:
######################################
root@it:~/EDID/edid-rw# sudo ./edid-rw 6 | edid-decode
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 4d 10 ff 13 00 00 00 00 00 17
version: 01 04
basic params: a5 1d 11 78 06
chroma info: de 50 a3 54 4c 99 26 0f 50 54
established: 00 00 00
standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1: 56 5e 00 a0 a0 a0 29 50 30 20 35 00 26 a5 10 00 00 18
descriptor 2: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 4: 00 00 00 fc 00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20
extensions: 00
checksum: b0

Manufacturer: SHP Model 13ff Serial Number 0
Made week 0 of 2013
EDID version: 1.4
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 29 cm x 17 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 241.500 MHz, 294 mm x 165 mm
2560 2608 2640 2720 hborder 0
1440 1443 1448 1481 vborder 0
-hsync -vsync
Dummy block
Dummy block
Monitor name: LQ133T1JW02
Checksum: 0xb0
EDID block does NOT conform to EDID 1.3!
Missing monitor ranges
root@it:~/EDID/edid-rw#

######################################

Good, so we're looking at the same thing. If you've made it this far
then we're pretty much finished.

IF you have an edid address different from 50, then we need
to change the write-edid.sh script accordingly (diy or report this).
If it is the standard address 50, then proceed:

Let's rewrite the edid (the .bin you copied to the 'write-edid' folder).
We'll presume it's called ABCDEF.bin. The actual tool it uses is i2cset
(docs bookmarked), but this writes byte-for-byte, whereas
the write-edid.sh script automates that (with address=50 pre-set).

12 cd ..
13 cd write-edid
14 sudo bash ./write-edid.sh 6 ABCDEF.bin

result:
######################################
root@it:~/EDID/write-edid# sudo bash ./write-edid.sh 6 SHP13FFmod.bin
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x00
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x01
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x02
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x03
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x04
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x05
Writing byte 0xFF to bus 6, chip-adress 0x50, data-adress 0x06
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x07
Writing byte 0x30 to bus 6, chip-adress 0x50, data-adress 0x08
Writing byte 0xE4 to bus 6, chip-adress 0x50, data-adress 0x09
Writing byte 0x6C to bus 6, chip-adress 0x50, data-adress 0x0a
Writing byte 0x04 to bus 6, chip-adress 0x50, data-adress 0x0b
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0c
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0e
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x0f
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x10
Writing byte 0x18 to bus 6, chip-adress 0x50, data-adress 0x11
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x12
Writing byte 0x04 to bus 6, chip-adress 0x50, data-adress 0x13
Writing byte 0xA5 to bus 6, chip-adress 0x50, data-adress 0x14
Writing byte 0x1D to bus 6, chip-adress 0x50, data-adress 0x15
Writing byte 0x11 to bus 6, chip-adress 0x50, data-adress 0x16
Writing byte 0x78 to bus 6, chip-adress 0x50, data-adress 0x17
Writing byte 0x06 to bus 6, chip-adress 0x50, data-adress 0x18
Writing byte 0xDE to bus 6, chip-adress 0x50, data-adress 0x19
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x1a
Writing byte 0xA3 to bus 6, chip-adress 0x50, data-adress 0x1b
Writing byte 0x54 to bus 6, chip-adress 0x50, data-adress 0x1c
Writing byte 0x4C to bus 6, chip-adress 0x50, data-adress 0x1d
Writing byte 0x99 to bus 6, chip-adress 0x50, data-adress 0x1e
Writing byte 0x26 to bus 6, chip-adress 0x50, data-adress 0x1f
Writing byte 0x0F to bus 6, chip-adress 0x50, data-adress 0x20
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x21
Writing byte 0x54 to bus 6, chip-adress 0x50, data-adress 0x22
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x23
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x24
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x25
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x26
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x27
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x28
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x29
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2a
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2b
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2c
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2d
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2e
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x2f
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x30
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x31
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x32
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x33
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x34
Writing byte 0x01 to bus 6, chip-adress 0x50, data-adress 0x35
Writing byte 0x2A to bus 6, chip-adress 0x50, data-adress 0x36
Writing byte 0x44 to bus 6, chip-adress 0x50, data-adress 0x37
Writing byte 0x80 to bus 6, chip-adress 0x50, data-adress 0x38
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x39
Writing byte 0x70 to bus 6, chip-adress 0x50, data-adress 0x3a
Writing byte 0x38 to bus 6, chip-adress 0x50, data-adress 0x3b
Writing byte 0x27 to bus 6, chip-adress 0x50, data-adress 0x3c
Writing byte 0x40 to bus 6, chip-adress 0x50, data-adress 0x3d
Writing byte 0x30 to bus 6, chip-adress 0x50, data-adress 0x3e
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x3f
Writing byte 0x35 to bus 6, chip-adress 0x50, data-adress 0x40
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x41
Writing byte 0x26 to bus 6, chip-adress 0x50, data-adress 0x42
Writing byte 0xA5 to bus 6, chip-adress 0x50, data-adress 0x43
Writing byte 0x10 to bus 6, chip-adress 0x50, data-adress 0x44
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x45
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x46
Writing byte 0x18 to bus 6, chip-adress 0x50, data-adress 0x47
Writing byte 0x56 to bus 6, chip-adress 0x50, data-adress 0x48
Writing byte 0x5E to bus 6, chip-adress 0x50, data-adress 0x49
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x4a
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x4b
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x4c
Writing byte 0xA0 to bus 6, chip-adress 0x50, data-adress 0x4d
Writing byte 0x29 to bus 6, chip-adress 0x50, data-adress 0x4e
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x4f
Writing byte 0x30 to bus 6, chip-adress 0x50, data-adress 0x50
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x51
Writing byte 0x35 to bus 6, chip-adress 0x50, data-adress 0x52
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x53
Writing byte 0x26 to bus 6, chip-adress 0x50, data-adress 0x54
Writing byte 0xA5 to bus 6, chip-adress 0x50, data-adress 0x55
Writing byte 0x10 to bus 6, chip-adress 0x50, data-adress 0x56
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x57
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x58
Writing byte 0x18 to bus 6, chip-adress 0x50, data-adress 0x59
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5a
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5b
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5c
Writing byte 0xFE to bus 6, chip-adress 0x50, data-adress 0x5d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x5e
Writing byte 0x4C to bus 6, chip-adress 0x50, data-adress 0x5f
Writing byte 0x47 to bus 6, chip-adress 0x50, data-adress 0x60
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x61
Writing byte 0x44 to bus 6, chip-adress 0x50, data-adress 0x62
Writing byte 0x69 to bus 6, chip-adress 0x50, data-adress 0x63
Writing byte 0x73 to bus 6, chip-adress 0x50, data-adress 0x64
Writing byte 0x70 to bus 6, chip-adress 0x50, data-adress 0x65
Writing byte 0x6C to bus 6, chip-adress 0x50, data-adress 0x66
Writing byte 0x61 to bus 6, chip-adress 0x50, data-adress 0x67
Writing byte 0x79 to bus 6, chip-adress 0x50, data-adress 0x68
Writing byte 0x0A to bus 6, chip-adress 0x50, data-adress 0x69
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x6a
Writing byte 0x20 to bus 6, chip-adress 0x50, data-adress 0x6b
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x6c
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x6d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x6e
Writing byte 0xFE to bus 6, chip-adress 0x50, data-adress 0x6f
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x70
Writing byte 0x4C to bus 6, chip-adress 0x50, data-adress 0x71
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x72
Writing byte 0x31 to bus 6, chip-adress 0x50, data-adress 0x73
Writing byte 0x37 to bus 6, chip-adress 0x50, data-adress 0x74
Writing byte 0x33 to bus 6, chip-adress 0x50, data-adress 0x75
Writing byte 0x57 to bus 6, chip-adress 0x50, data-adress 0x76
Writing byte 0x46 to bus 6, chip-adress 0x50, data-adress 0x77
Writing byte 0x34 to bus 6, chip-adress 0x50, data-adress 0x78
Writing byte 0x2D to bus 6, chip-adress 0x50, data-adress 0x79
Writing byte 0x53 to bus 6, chip-adress 0x50, data-adress 0x7a
Writing byte 0x50 to bus 6, chip-adress 0x50, data-adress 0x7b
Writing byte 0x44 to bus 6, chip-adress 0x50, data-adress 0x7c
Writing byte 0x31 to bus 6, chip-adress 0x50, data-adress 0x7d
Writing byte 0x00 to bus 6, chip-adress 0x50, data-adress 0x7e
Writing byte 0x6B to bus 6, chip-adress 0x50, data-adress 0x7f
Writing done, here is the output of i2cdump -y 6 0x50:
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4d 10 ff 13 00 00 00 00 ........M?.?....
10: 00 17 01 04 a5 1d 11 78 06 de 50 a3 54 4c 99 26 .??????x??P?TL?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 ?PT...??????????
30: 01 01 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20 ??????V^.???)P0
40: 35 00 26 a5 10 00 00 18 00 00 00 10 00 00 00 00 5.&??..?...?....
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 .............?..
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc ...............?
70: 00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20 00 b0 .LQ133T1JW02? .?
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
######################################

So ... it's the same edid ... Seems my eeprom is already
write-protected (unfortunately, for me; it'd be 75Hz otherwise).
If successful then you should have a different edid than before
and your panel is fixed.

There's also a vcom eeprom, but let's not get into that right now.

finish

 

Hi Agil1ty.

Thanks! I'll try this out, once I get back to my laptop. Now a couple of questions.

Assuming I made it to the point where I could follow the instructions posted by user t456.

The instructions assume that the reader is using his Live Ubuntu with edid tools image, where all the instructions, folders, files and website bookmarks have all been set up.

That means with a fresh ubuntu image I probably wouldnt have the exact things he's talking about, unless the EDID.zip file you're sending me has all the tools mentioned in the instruction.

But I shouldn't get ahead of myself. Once I get to that point I will solicit your help once more.

 

Hi Agility.
I've booted into Ubuntu, used 2ndary monitor to mirror my laptop's display, installed all the repositories, updated them, and installed i2ctool.

I thought I was ready for the instruction but when I type 'sudo sensors-detect' I get:
sudo: sensors-detect: command not found.

I suspect this is pathing issue more than anything. Any idea? I really know nothing about nothing.

Thanks, Agil1ty!

 

Sup, its me again . You need to install the lm-sensors package with "sudo apt install lm-sensors" to get the sensors-detect command.

 

For me, however, the output of "sudo i2cdetect -l" only gives me one SMBus device - there are no i2c-X. I tried the "acpi_enforce_resources=lax" kernel parameter, but it is still the same. Did you encounter a similar problem @Agil1ty?

 

I fixed it! I posted a write-up over in this thread. I believe that only a SMBus appeared in my i2cdetect because I didn't attach an external display when I did this, which meant I was using the internal display (with safe graphics).

 

hi all,
I have a screen B156RW01 v1. I have downloaded the EDID text file on github ( AUO01EE)
I also followed the command file on lubuntu to convert the txt file to bin file. But when I test it with edid-decode it gives me a blank file
Can somebody help me and share the bin file of the B156RW01 v1 screen?
That would be greatly appreciated.
Thanks a lot