Resuscitare ecran Clevo 377sm-a

rodarkone · 01-06-2017, 09:37

Dragii mei azi am reusit sa resuscitez ecranul laptopului prin rescrierea EDID-ului (Extended Display Identification Data)

Pentru un pic de background info puteti citi aici -> http://forum.lab501.ro/showpost.php?...&postcount=388

Am urmat ghidul de aici:

http://forum.notebookreview.com/thre...#post-10170202

Mi-a tremurat un pic mana pentru ca nu am stitu cum a fost facuta imaginea si mai ales ca nu am putut urma tutorialul 1:1

Insa sunt bucuros asa ca iata aici pasii pe care i-am facut eu (separati de tutorial)

Am uitat sa mentionez:

(hiccups) Initial am rulat prin HDMI pe ecranul pe care il am ca primary display, insa nu s-a inteles de nici o culoare ci imaginea de linux / norocul meu ca aveam mini-display to VGA si am rulat totul pe un monitor vechi (17") prin VGA cable

01 check 'pnp id -panel nrs.txt' for the correct bin (in the 'archive' folder)
02 copy it to the 'write-edid' folder
03 open terminal (ctr+alt+T)
04 sudo bash
05 sudo sensors-detect - (aici este un pic confuz.. pentru ca intrebarea despre I2C/SMBus vine a 3-a sau a 4-a si apoi urmeaza o droaie, in functie de cate device-uri identifica)

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), (a mea tot i2c-i801 a fost)
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: (mie aici mi-a dat cu virgula, toate device-urile erau recunoscute cu nouveau-0000 (asa ca am inceput sa le verific 1 cate 1 .. si eu am avut 43)
######################################
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 (eu am rulat dump-ul pentru absolut toate cele 43 bus-uri)

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 (la mine a fost al 2 lea) si diferenta e ca a fost pe 256 biti EDID-ul omu zice ca tre sa folosesti scriptul pe 256 (mai jos, insa e usor de "scapat" asa ca aici trebuie un pic de atentie)

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 (nu am reusit sa export, imi face un file gol .. cred ca trebuia undeva un write / pe vreun folder, sincer n-am verificat)

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: /// ..................................... eu am sarit pasul asta

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 ..................... probabil cel mai important pas (pentru ca aici vezi adresa unde trebuie sa scrii)

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). (aici e iar un pas important, eu am avut ceva scris la adresa 50 )

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

10 cd EDID/edid-rw

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

11 sudo ./edid-rw 6 | edid-decode (un pas esential - el il considera doar un checsum - aici vezi exact daca la adresa de bus este un ecran sau altceva

- daca e ecran apar informatii precum rezolutia ..e tc ) .. idiotii modifica EDID partea asta ->

Digital display
8 bits per primary color channel

eu aveam

Analog display si ceva bla bla cu un voltaj extrem de mic (practic monitorul nu se aprindea)

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 (partea asta e simpla de tot - eu neavand scriptul in aceelasi folder am schimbat doar calea cu cea corecta / evident pe bus-ul corect si cu *.Bin-ul corect)

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
*** edited // oricum e irelevant pentru ca difera de la caz la caz
######################################

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

PRostul a scris ce a vrut el .. i-am dat restart la laptop si ZBANG

a pornit la prima cheie

sunt foarte happy (si e cam 2:30 dimineata) - daca e cineva in situatie similara, sa-mi lase un PM si il pot ajuta cu sfaturi

La final fun facts:

0. am schimbat 5 ecrane si 2 placi de baza pentru a corecta problema, stand cu laptopul pe butuci aproape 1 an si jumatate si ajungand la capatul puterilor (rabdarii mai curand) am zis sa iau alt laptop.
1. acum 2-3 zile am comandat ecran de schimb SH

65 $ aruncati la gunoi (sau ma rog .. "cheltuiti aiurea") pe un ecran despre care nu stiu nimic
2-a fleasca, acum 1 saptamana am comandat laptop now

2000 $ aruncati in vant

Sper sa nu se considere ca vreau sa insult prin a-mi asuma vreun merit care nu-mi apartine, toate multumirile merg catre:

1. t456 - de pe forumul notebookreview (el a facut ghidul si a creat imaginea de lubuntu care contine toate fisierele necesare, plus ca e foarte bine documentat si relativ usor de folosit, as putea spune ghid cu risc mare si dificultate medie, desi folosesc computere de ~ 20 ani, nu ma pot declara un super-expert si totusi am reusit)
2. premo - de pe forumul notebookreview/techinferno
3. mr.fox - forumul notebookreview/techinferno
4. nu in ultimul rand lui @carcozep pentru ca mi-a aratat calea

agarici cu pedale · 01-06-2017, 13:00

felicitari, asta da lucru manual si executat cu sudoare ca sa zic asa.

de asta ma feresc de producatori aiurea cand vine vorba de bani multi chiar daca produsul e premium, sunt prea putini consumeri pe nisa aia, mai ales pe produsul in cazul tau clevo , adica sanse minime de raparatie acasa fiindca nu exista info destule.

again, felicitari, piesele de ti-au ramas pune-le la vanzare pe olx sau oriunde altundeva ca sa scapi de ele altfel ajung la gunoi sooner or later.

rodarkone · 01-06-2017, 15:52

Problema a fost "identificata" pe Alienware (Dell) si ulterior s-a constatat ca afecteaza si Clevo.

Se pare ca vinovatul este Precision X al celor de la evga

agarici cu pedale · 01-06-2017, 16:48

what the fuck ?

carcozep · 01-06-2017, 22:28

@rodarkone: Ma bucur ca am putut sa-ti fiu de ajutor

Fain ghid

@agarici cu pedale: Treaba e usor complicata. Initial, combinatia de Windows 10 + orice driver mai nou de o anumita data => EDID Corupt. Insa in timp au aparut multe alte marturii de la persoane cu Windows 7/8.1 care s-au trezit cu ecranul negru si bip bip bip.

Cei de pe notebookreview forum au trimis ecranele stricate celor de la NVida ca sa reproduca problema. Doar ca raspunsul intotdeauna era "we weren't able to reproduce this issue". Se acumulau in continuare marturii legate de problema asta, dar la capatul NVidia nu se manifesta nimic. Pana cand au primit un pont legat de EVGA Precision X si cum au instalat aplicatia la scurt timp au putut sa reproduca problema.

Continuarea? NVidia au fost extraordinari de bucurosi sa arunce cartoful fierbinte in ograda EVGA. Desi au fost numeroase cazuri cu persoane care n-au avut niciodata acel soft, NVidia nu a sapat mai adanc sa gaseasca problema in driverii lor. Au fost bucurosi ca au pe cine sa dea vina.

Microsoft? N-au raspuns nici pana in ziua de azi cum de Windows 10 permitea un asemenea acces liber la modificarea parametrilor EDID. Au fost cei mai lipsiti de interes in a rezolva o problema care afecta laptopuri vandute cu licenta de Windows 10. Pentru ca de ce te-ai obosi sa cauti buba din OS care permite EDID-ului sa ajunga corupt? Madness right?

Si dupa tot acest fiasco, Intel a luat decizia de a adauga aceasta modificare in ultimii lor driveri pentru placile video integrate din generatia Haswell:

Quote:

Intel graphics drivers are now accessible to 3rd party EDID tools.
It is now possible to use 3rd party EDID utilities to manipulate EDID settings to create custom modes.

WHAT CAN GO WRONG?

agarici cu pedale · 02-06-2017, 09:57

Merci de explicatie, still wa da fac !
In ziua de astazi absolut toti fac asa, arunca mingea in curtea celuilalt sau zic ca l-ai belit tu, nici nu ma mai mira, oricum sad shit.

Ma bucur ca l-ai rezolvat pe "fraier" si acum functioneaza.
Pacat de timpul pierdut pentru o situatie penibila care a trecut de QA si a fost released. Thx intel.

kobro · 02-06-2017, 22:33

Foarte interesant !
Pe mine ma interesa cum sa fac sa afiseze corect rezolutii pt vga vechi pe ecrane wide, dar nu mi-am gasit suficient timp.
Acuma imi dai curaj pentru un nou research