Problems? See this thread at archive.org.
Yes @vlad100, like your notebook can't boot without an working LCD, the best option is send it to @Mr.Fox. No doubt.
Good luck and keep posting here as you need.
-
Well, I'm pretty sure that my utter lack of knowledge regarding the matter provided the answer
No, all I had to do on my part was update the BIOS to A12 and hard-mod the heatsinks. Cards came with Prema vBIOS, thanks to Woodzstack. The rest works fine - stock drivers, fans, etc. -
Hey guys. My Panther (P570WM) got its 60Hz LCD bricked by EVGA Precision X. I restored a Windows 10 drive image that had it installed and did not realize it until is was too late. Only had a black screen and could not access the BIOS and could not see anything at all until reaching the Windows desktop, then the registry EDID would kick in and the screen would light up. (Not good, but better than 8 beeps and no boot like Alienware.) I did not have an EDID.BIN file, but found a good EDID in the registry that I saved to a BIN file and wrote that to the display panel to fix it.
Booting from HDMI to the Alienware 18 screen (using HDMI input feature) I used @t456 bootable Linux tool kit to fix it. As you can see from the mess below, EVGA reprogrammed it from digital to analog display, LOL. Luckily, I was able to do a "flash in place" using this method.
@Prema @Kpaxx @johnksss @Takaezo - FYI - I think you all have eDP 120Hz, so you *might* be safeCode:<<<<BEFORE FLASHING>>>> lubuntu@lubuntu:~/EDID/edid-rw$ sudo ./edid-rw 1 | edid-decode Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 06 af 9d 14 00 00 00 00 01 13 version: 01 03 basic params: 00 26 15 78 0a chroma info: 7d 45 ab 4f 38 a6 24 12 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: a0 37 80 b4 70 38 32 40 6c 30 aa 00 7d d6 10 00 00 18 descriptor 2: 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20 descriptor 3: 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 descriptor 4: 00 00 00 fe 00 42 31 37 33 48 57 30 31 20 56 34 20 0a extensions: 00 checksum: f6 Manufacturer: AUO Model 149d Serial Number 0 Made week 1 of 2009 EDID version: 1.3 Analog display, Input voltage level: 0.7/0.3 V <<<<-LOOK HERE Sync: <<<<-LOOK HERE Maximum image size: 38 cm x 21 cm Gamma: 2.20 RGB color display First detailed timing is preferred timing Established timings supported: Standard timings supported: Detailed mode: Clock 142.400 MHz, 381 mm x 214 mm 1920 2028 2076 2100 hborder 0 1080 1090 1100 1130 vborder 0 -hsync -vsync Manufacturer-specified data, tag 15 ASCII string: AUO ASCII string: B173HW01 V4 Checksum: 0xf6 (should be 0x76) <<<<-LOOK HERE (SHOULD NOT BE 0x76) EDID block does NOT conform to EDID 1.3! Missing name descriptor Missing monitor ranges EDID block does not conform at all! Block has broken checksum <<<<AFTER FLASHING>>>> lubuntu@lubuntu:~/EDID/edid-rw$ sudo ./edid-rw 1 | edid-decode Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 06 af 9d 14 00 00 00 00 01 13 version: 01 03 basic params: 80 26 15 78 0a chroma info: 7d 45 ab 4f 38 a6 24 12 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: a0 37 80 b4 70 38 32 40 6c 30 aa 00 7d d6 10 00 00 18 descriptor 2: 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 20 descriptor 3: 00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20 descriptor 4: 00 00 00 fe 00 42 31 37 33 48 57 30 31 20 56 34 20 0a extensions: 00 checksum: f6 Manufacturer: AUO Model 149d Serial Number 0 Made week 1 of 2009 EDID version: 1.3 Digital display <<<<-LOOK HERE (CORRECTED) Maximum image size: 38 cm x 21 cm Gamma: 2.20 Supported color formats: RGB 4:4:4, YCrCb 4:2:2 First detailed timing is preferred timing Established timings supported: Standard timings supported: Detailed mode: Clock 142.400 MHz, 381 mm x 214 mm 1920 2028 2076 2100 hborder 0 1080 1090 1100 1130 vborder 0 -hsync -vsync Manufacturer-specified data, tag 15 ASCII string: AUO ASCII string: B173HW01 V4 Checksum: 0xf6 EDID block does NOT conform to EDID 1.3! Missing name descriptor Missing monitor ranges lubuntu@lubuntu:~/EDID/edid-rw$
I am attaching my P570WM 60Hz AUO EDID file in case anyone with the same panel needs it. @t456 may want to add it to his archive.
I used the File > Save As feature and selected .BIN as the file type for the registry EDID.
Prior to flashing, the "Real-time" line above the "Registry" line selected in the screen shot had gibberish instead of the actual AUO149D LCD model name.
Attached Files:
-
-
-
I have done that a few times. Flashed a few computers over teamviewer though.
ajc9988 likes this. -
Thanks
, added along with a few others:
archive correct edids, v10
Code:pnp id notes interf panel nr. edid eeprom ------- ----- ------ ------------- ------------------- AUO10ED ! LVDS B156HW01 V0 AUO12ED eDP B156HAN01.2 AUO149D ! LVDS B173HW01 V4 AUO159D LVDS B173HW01 V5 AUO219D ! LVDS B173HW02 V1 CMO1719 LVDS N173O6-L02 CMO1720 ! LVDS N173HGE-L11 LGD01CA LVDS LP173WD1-TLA1 LGD0226 LVDS LP173WD1-TLC2 LGD0285 LVDS LP173WF1-TLC1 LGD0289 LVDS LP173WD1-TLA3 LGD02C5 eDP LP173WF2-TPA1 LGD02DA ! LVDS LP173WF1-TLB3 LGD02FC C LVDS LP173WF3-SLB2 LGD0343 LVDS LP173WF1-TLB5 LGD037E LVDS LP156WF4-SLB5 LGD0391 LVDS LP173WD1-TLE1 LGD03FB LVDS LP173WF1-TL** LGD046C E eDP LP173WF4-SPD1 MEI96A2 eDP VVX16T020G00 SDC3654 LVDS LTN173KT03-W01 SDC4852 eDP LTN156FL02-L01 SDC4C48 ! LVDS LTM184HL01-C01 SEC314A LVDS LTN184HT03-001 SEC4A4B LVDS LTN184KT01-J01 SEC5044 !?AW eDP LTN173HT01-301 Winbond 25X20BLNIG SEC5044 !?AW eDP LTN173HT02-D** Winbond 25X20BLNIG ??????? A eDP LTN173HT02-D02 "" ? SEC5044 A eDP LTN173HT02-P01 "" ? SEC5044 A eDP LTN173HT02-T01 "" ? SEC5443 LVDS LTN170CT08-D01 SEC5448 ! LVDS LTN184HT02-S01 SEC544B B LVDS LTN173KT01-*** SEC544B BD LVDS LTN140KT**-*** ----------------------------------------------------------------------------------------------------- ! = known bricked panels !? = bricked, but unknown which one * = unknown part id A = highly suspect: multiple variants exist, perhaps the others are safe ... B = multiple variants, flash the correct one! C = EliteBook 8**0w DreamColor, 10-bit, for fun ^^ D = 14.0" version for M14x, just in case E = G-Sync approved panel (hint ^^) W = write-protect possible If multiple edids exist for one PnP id; flash the most recent edid, unless indicated otherwise. -----------------------------------------------------------------------------------------------------
Again, like every others known brick so far, the corruption was found at address 0x14:
![[IMG]](images/storyImages/vPfG.png)
Doesn't matter what else is amiss; address 0x14 is always affected. Something weird about your edid, btw; its ' color bit depth' is listed as ' undefined', even though both Panelook and the AUO specification sheet claim 6-bit (as is usual):
![[IMG]](images/storyImages/tVTS.png)
Not sure ... do you have 262K or 16.7M colours available? Kinda wonder whether this might explain the 90% gamut with the V4, which is not found with most of the others in the series. Chromaticity coordinates are still stock, so it hasn't been calibrated panel-by-panel, at least.
Anyway, will upload a new linux live image with the updated edid archive. Been long enough and the old thread is closed.CaerCadarn, RODBORA, Mr. Fox and 1 other person like this. -
I cannot identify any reason the stinking Nazis losers from Redmond need ANY low-level access to anything. If they cannot stop making an OS that is loaded with malware and taking inappropriate liberties then they need to send everyone home and shutter the campus. I'm just so sick and tired of their retarded baloney. I'm being kind here. If I said what really think about their nonsense it would violate my wholesome way of life and probably get me banned.
Thanks. Wasn't that big a deal, but I've been around the block with this stupid problem before. Thanks to @t456 and his helpfulness, it wasn't any harder to fix than flashing a vBIOS after I got everything ready. Dealing with their incompetence is more of a pain in the butt and huge inconvenience than anything else... but, what's not to love about a disaster being diverted, right? Got to be happy about that, for sure.
Thanks for making everything so easy. You're awesome buddy.
Yeah, the Alienware thread kept turning into an off-topic chat forum. Hard to resist and stay on topic when people like each other, but it was constant, LOL. I even had to slap my own wrist a few times, so I just shut 'er down.
How can I tell how many colors? This is stuff I never pay any attention to. All I know about is it is "True Color (32-bit)" for Aero to work. As long as it looks good to my eyes and not any lower than 1080p I don't pay any attention to the other stuff. I'd rather focus on overclocking and benching more than high-falutin pixel stuff.
-
Hi!
Nah, no issues thus far. I used CRU to overclock my panel from 60 to 110Hz, which is what runs on my laptop 24/7 now and I use Nvidia Inspector for my monitoring and clock/mem OC needs. Never touched any of them fancy softwares like Precision X as I believe that the simple tools like Inspector do the job just as well.
Win10 Pro here, latest Nvidia drivers for 980M. I bet I would have noticed by now as my lappy is up and running 24/7
Does anyone know if Windows editions maybe make a difference? I'm on Pro, how about the people who've got their screens bricked? I know it's a shot in the air, but you, of all people, know that ridiculous things can happen with computers triggered by seemingly meaningless things... (I've had a brand new ASUS laptop whose audio jack would not output to speakers/headphones. Later found out that it happened because I disabled the startup/POST jingle when ASUS logo was showing...wtf?!)PC GAMER likes this. -
Beats me. Both HWiNFO and MonInfo can tell you, but think you can guess where they get their data from ...
. Your V4 likely says 'unknown'/'undefined', instead of something useful. No idea otherwise (save an excellent calibration result ... ).
![[IMG]](images/storyImages/OMXvGNd.png)
Live and persistent Linux with edid tools (760 MB)
Changes:
- far more edids in archive (main reason for new version)
- slightly re-organised
- slightly smaller (-1% )
- spelling (ahem
)
- live -> no install required
- persistent -> changes stick, even after reboot
- dual boot uefi+legacy -> in case of impossibility to switch
- small -> downloadable(-ish)
![[IMG]](images/storyImages/N5N6zRP.png)
Instructions to write to stick:
![[IMG]](images/storyImages/usb-image-tool-restore.png)
- It can be written to a 1GB usb stick (or drive) using USB Image Tool.
- Don't use 'apt-get update'; Linux isn't 100% perfect either and some older systems didn't seem to like this. If you can't boot it any more; rewrite the image to the stick, that's all.
- Read, comprehend and follow the instructions below (in that order, preferably
).
Code:start 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 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
See folder ' home -> EDID -> archive' for the correct edids. Everything else is in the EDID folder as well, including the instructions and edid tools. Firefox has the proper websites, guides and documentation bookmarked, that way you can keep them open side-by-side to the console. There's also a few screenshots (uncommented) and an easy-extract spreadsheet. This strips the backup or ic2dump output of the row and column headers, that way you can copy/paste it to the Web Based EDID Reader and check the data.
Good luck !
Last edited: Jul 30, 2016Hirosake, plasmamax1, triturbo and 16 others like this. -
Is this the UEFI bootable one ?
I tried everything but every time I try to get past the "try Ubuntu without installing" screen ... I get a black screen and have to force shutdown.
I am booting along W8.1 UEFI and tried every trick in the book and can't get it to work
Last edited: Jan 3, 2016 -
-
Actually currently my new screen is working. I am trying to have this ready as fail safe for when the screen gets corrupted
-
Hi, would anyone be kind enough to give me some advice on what risk there is in me upgrading to Windows 10.
The reason I ask is that I have a Clevo P771ZM, 4690K and 980m. (which seems to an affected model?)
I'm currently running Win 8.1, with a mild overclock/undervolt on the 4690K (Intel XTU) and basically stock 980m. Afterburner is my program of choice for keeping a check on the 980m, and I have very rarely used a small overclock using Afterburner. I did install EVGA Precision once upon a time, but didnt use it for anything, so uninstalled it.
I have been resisting the upgrade (and putting up with constant upgrade reminders) due to the issue discussed in this thread , with what seems to be a likelyhood to flash the LCD and 'brick' it. Is this still the case?
It would be nice to upgrade, but are there anyways to eliminate ALL risk of bricking something? Driver issues I can cope with, but I would rather not have to go down the road of flashing stuff
Also I suppose a nail in coffin for a possible Win 10 upgrade is that Win 8.1 works faultlessly for me, no crashes, hangs, lockups, or anything, and games fly
Cheers
Mick -
It should do both uefi and legacy, whatever you have set in the bios. Should guess that Secure Boot is a big no-no with this image (can't test that myself, plus; it's evil, anyway). Failing that; enable csm/compatibility mode.
If neither works then the image just needs an update for the display driver. Might add it with the next update, just in case. GPU drivers are, of course, top-heavy and storage space is at a premium , so let's hope it's not necessary.
MahmoudDewy and Mr. Fox like this. -
I have the Chi Mei TN
I'm thinking along those lines
-
-
MSI Afterburner is not an acceptable alternative for GPU overclocking due to the lack of voltage control for notebooks. For those that have not already discovered it, ASUS GPU Tweak has voltage control for notebook GPUs, so that may be a safe alternative to EVGA Precision X if you find NVIDIA Inspector to be as cumbersome and slow to deal with as I do. Notice that I said "may be safe" because I don't know for certain whether or not whatever EVGA Precision X does to corrupted EDID is an exclusive "feature" of Precision X.
***EVGA Precision X and Windows 7/8/8.1 and especially 10 bricking systems***
Discussion in 'Sager and Clevo' started by Ethrem, Sep 14, 2015.
