*** Windows 10 + NVIDIA WHQL Drivers are Killing Alienware and Clevo LCD Panels ***

jst.what.exaxtly is the real.problem ...if.its a.driver releated problem is it with the latest.nvidia driver . does it effect only laptops

Sent from Galaxy Note 5 via Tapatalk

 

Go back to page 1 and read the first two posts. Or even skim them. It's all there.

 

Yeah and don't forget Clevo machines are affected too but not as easily (?), but there are definitely reports like my case.

 

Nice. If dell will be fixing this then M18xR1/R2 machines are out of luck. Only AW18 will probably get a fix.

 

is it going to be a software patch or update

Sent from Galaxy Note 5 via Tapatalk

 

What I find unsettling is that you will find tons of links about Windoofs10 beeing a crappy OS with a more crappy Micro$lut Support to "help" their customers out, but it still didn't reach public Level yet!?

http://www.infoworld.com/article/29...iew-hold-off-if-you-use-windows-7.html?page=2

The comments are most like ours here and you will find it throughout almost every page with a Windoofs10 review. So the majority (regarding the comments on the links) find it crappy too, so I guess! But I still wonder why it hasn't popped up in the channels, TV, Newspaper, etc., yet.
What you will find is more like: "Oh, there are some reported bugs about some bricked LCD's, failed installations, non functional System Recovery to go back and so on.... But it will probably be fixed soon and then Windoofs10 is a great OS, bla bla bla...."

Would laugh my ar** off, if someone like John Oliver would pick up this theme in his LastWeekTonight. Oh that would be.... most entertaining!

 

@Arestavo
Mr. Fox replaced his hard drive and fresh installed Windows 7 and it still bricked. Most likely need a new Motherboard and/or RAM to prevent the EDID cancer from spreading. Even snipping the writing portion of the cable (#5) doesn't solve the issue.

 

still trying to reproduce the issue on my Clevo P771ZM, so far i had no issues since 1 day, even upgraded to the lastest WHQL and went back to the 355.84 Dev Drivers, everything is still working

 

Can your Clevo run in discrete graphics mode only? This is the way I was able to corrupt all of my screens switching to discrete then trying to copy my vBios with the windows version of NvFlash then restarting machine.

 

yep the Clevo P771ZM, only has discrete mode (thank god), i bricked it before somehow upgrading from 355.60 to 355.82 or it was even bricked before but didn't notice, reflashed EDID with Linux Method and since then there wasn't any issues anymore. Yesterday i reflashed Prema Bios v2 and reinstalled W10 but this time clean instead of upgrade method.

 

I just thought I'd mention that NVIDIA has released 355.98 WHQL drivers, in case anyone was doing any testing on every driver version.

 

Don't know for sure, but if I am not mistaken most of the "Problems" ocurred while upgrading. I didn't heard such by installing it as a fresh install.

Could it be an "upgrade" issue then? Not that it makes it better though....

 

@Scerate: what exactly did u change in your config to get "trouble reproducing the issue"?

edit: nevermind, the post order got messed up somehow so i only just now read the details

 

Am i screwed? I got my M18x R2 yesterday 780m sli.. installed windows 10 and was about to install Nvidia drivers and thankfully come across this! but.. has windows 10 written that EDID already or will I be ok if I install windows 8.1? I installed with full UEFI as well, what a nob

 

Chances are win10 has already done its dirty work in your BIOS so even if you roll back to win8.1 it may still corrupt your EDID when you install the nvidia drivers.
You will know when your EDID is corrupt because the display wont work anymore when you startup from a cold boot.

 

My observation is this, if MicroSoft and/or NVidia can screw things up, they can be unscrewed. The programmers that thought of how to do it were in class with either smarter or shiftier people than themselves. It seems to me that the brute fix is now available via the blind EDID flash route. Now, there are a finite number of places new code could have been written to make it continue to happen after a BIOS and/or hard drive wipe. Are any tools available to read/write this MicroSoft "infect my Windows computer" area, I mean Windows Platform Binary Table? Are there any other places code can be written at the motherboard level?

Homer

 

Get an EDID Report in .txt, copy that and put it into the EDID-Reader. If it says it's okay, then you might be lucky. If not, it seems only a matter of time when your Screen will die....

 

So stressful! so.. is it still a no go if I flash the BIOS and install windows 8.1?

 

How please? I'll Google in the mean time to see if I can do it

 

Unfortunately it also befalls rig's that have been converted back to 8.1/7 by additionally flashing the BIOS, formatting the c:\ Drive or even a new one, like Mr. Fox sadly demonstrated....

But give it a try! Do a fresh and clean install.... and wait!

 

Copy & paste your EDID-Report here:

http://www.edidreader.com/

Edit: You should be able to save your Report as a .txt-file.

 

Screenshot posted in previous page mate

 

I realise that, but it's only half the battle!

You have to save it as a txt-file and copy & paste it in above mentioned Reader and only, if the checksum is "true", then it is okay, for now

 

This is only what is stored in the registery, not direct from the chip on the display. So your display could be corrupted while running / installing drivers, but it will still work fine until you restart and the bios tries to read the EDID info.

 

installed windows 8.1 - ill try EDID and save, windows 10 wouldn't output the txt file and also ***My LCD is reporting 64HZ!** is this it?? is this whats going to slowly fry my lcd

 

failed to extract EDID do I need to be connected to an external monitor or something? same output as windows 10

 

@t456: any advice? My competencies ends here.

 

http://www.entechtaiwan.com/util/moninfo.shtm
But this only gives you what is in the registry from the last cold boot of your machine. It will not tell you in 'real time' what info is in the EDID

 

AFAIK there's real-time option in MonInfo

 

Ah, that was the missing Piece! moninfo + edidreader

Thanks for pointing it out!

@mrsweet1991: You can give it a try. Shouldn't hurt!

 

ok, I had a program that opened it up like that, but how do I convert to txt for that edid reader? it only gives bin and hex as an output I think

 

Hex is good, but as pointed out; neither MonInfo, DumpEDID or AIDA64 will not show you the values on the eeprom itself. They all extract the registry version only. For an eeprom extract; use the DOS or Linux tools (links at the end).

The 64Hz is not a good sign, btw ...

 

Monitor Asset Manager Report, generated 23/09/2015
Copyright (c) 1995-2014, EnTech Taiwan.
---------------------------

---------------------------

Hardware data
BUS_SLOT = PCI00000.PCI00004.PCI00008.PCI0000C.PCI00010.PCI00014.PCI00018.PCI0001C
00000000 = 01548086.20900006.06000009.00000000.00000000.00000000.00000000.00000000
00000008 = 01518086.00100007.06040009.00810010.00000000.00000000.00060100.20005050
000000A0 = 1E318086.02900406.0C033004.00000000.D5400004.00000000.00000000.00000000
000000B0 = 1E3A8086.00100006.07800004.00800000.D5414004.00000000.00000000.00000000
000000D0 = 1E2D8086.02900006.0C032004.00000000.D5419000.00000000.00000000.00000000
000000D8 = 1E208086.00100006.04030004.00000010.D5410004.00000000.00000000.00000000
000000E0 = 1E108086.00100007.060400C4.00810010.00000000.00000000.00080800.00003030
000000E8 = 1E268086.02900006.0C032004.00000000.D5418000.00000000.00000000.00000000
000000F8 = 1E578086.02100007.06010004.00800000.00000000.00000000.00000000.00000000
000000FA = 1E038086.02B00007.01060104.00000000.00006049.00006055.00006041.00006051
000000FB = 1E228086.02800003.0C050004.00000000.D5415004.00000000.00000000.00000000
000000FE = 1E248086.00100000.11800004.00000000.00000004.00000000.00000000.00000000
00000100 = 119F10DE.00100407.030000A1.00800010.D6000000.A000000C.00000000.B000000C
00000101 = 0E0A10DE.00100006.040300A1.00800010.D7000000.00000000.00000000.00000000
00000700 = 119F10DE.00100006.030000A1.00800010.D4000000.C000000C.00000000.D000000C
00000701 = 0E0A10DE.00100006.040300A1.00800010.D5000000.00000000.00000000.00000000
00000800 = 10831969.00100007.020000C0.00000010.D5300004.00000000.00003001.00000000
00000900 = 0030168C.00100546.02800001.00000010.D5200004.00000000.00000000.00000000
00000A00 = 520910EC.00100406.FF000001.00800010.D5101000.00000000.00000000.00000000
00000A01 = 520910EC.00100006.08050001.00800010.D5100000.00000000.00000000.00000000
--------

 

Where are the links mate?

 

Downloaded the DOS file you linked, I only prey I actually come back to the desktop after reboot

 

How do I run the DOS file you linked? if I try to extract the .img it just says it's corrupted winrar that is anyway.

 

Hey

I did not know how he would like to do it but i think this one should work - http://www.askvg.com/win32-disk-imager-write-any-bootable-image-to-usb-drive-in-windows/

 

It's ok I done it now, used 7-zip, extracted the zip then extracted the .img

 

Nope. You should write it to pendrive, not unpack using 7-zip. Write to pendrive using that tool and boot from usb.

 

Funny you should mention that; been reading a bit on CompuTrace/LoJack, which uses the same technology.

Lenovo used Windows anti-theft feature to install persistent crapware:

The right term here is not ' insane', that wouldn't cut it ... it's dangerous, to boot.

Everything about this would explain the 'infection' we've seen so far, except the ' bios flash = fail'. Fortunately, the creator of this rootkit provides the answer in their FAQ:

How ... 'innovative' ...

Checked my 7's autochk.exe files, needless to say:

Code:

sfc /VERIFYFILE=C:\Windows\System32\autochk.exe
sfc /VERIFYFILE=C:\Windows\SysWOW64\autochk.exe

And hex-searched both for 'http'-like traces; all clean. But now for the infected systems? Upload them too, please. Ah, and for 8.x/10 systems:

Of course, it didn't have to be this exact product; someone else may have used the same rootkit technology. All we need is a bios compare of an infected system (nvram cleared) and an extracted pre-flash bios. Also, attempted an exorcism of the Secure Boot module, but maybe a tad too rigorous; flashing that bricked the system . No matter, removing the module alone and the ' key database' should suffice, only need to locate it first ...

 

Do you have the .bin files on the usb stick? If so, upload them or just copy/paste their hex values to the edid reader site.

 

Are you referring to the bin files created by the software I used or the DOS app that I ran from the USB? if from the USB I didn't think to look at it given the error I received? And the post previous to that is so mind boggling =O and is it because I've not installed any nVidia drivers why my LCD is still working?

 

That tool would not work for me. I ended up extracting and copying and then it worked for the Linux Tools.

Installed NVIDIA's brand new driver on the M18xR1 (never touched by Windows 10) and the M18xR2 this morning. M18xR1 is working normally. M18xR2 LCD is bricked again. Block 14 was changed from 90 to 00. The web-based EDID reader says it is good, but we know it's not. So, don't trust it 100%.

Good EDID:

Code:

00 ff ff ff ff ff ff 00 4c a3 48 54 00 00 00 00
00 14 01 04 90 29 17 78 0a c8 95 9e 57 54 92 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 29 36 80 a0 70 38 1f 40 18 10
25 00 99 e6 10 00 00 1a 1c 24 80 a0 70 38 1f 40
18 10 25 00 99 e6 10 00 00 1a 00 00 00 fc 00 4c
54 4e 31 38 34 48 54 30 32 53 30 31 00 00 00 fe
00 4d 72 2e 20 46 6f 78 27 73 20 6c 63 64 00 b8 

Today's Corrupted EDID:

Code:

00 ff ff ff ff ff ff 00 4c a3 48 54 00 00 00 00
00 14 01 04 00 29 17 78 0a c8 95 9e 57 54 92 26
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 29 36 80 a0 70 38 1f 40 18 10
25 00 99 e6 10 00 00 1a 1c 24 80 a0 70 38 1f 40
18 10 25 00 99 e6 10 00 00 1a 00 00 00 fc 00 4c
54 4e 31 38 34 48 54 30 32 53 30 31 00 00 00 fe
00 4d 72 2e 20 46 6f 78 27 73 20 6c 63 64 00 b8

 

Fox. Your Good EDID is different mine

Code:

0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x4C 0xA3 0x48 0x54 0x00 0x00 0x00 0x00 0x00 0x14 0x01 0x04 0x90 0x29 0x17 0x78 0x0A 0xC8 0x95 0x9E 0x57 0x54 0x92 0x26 0x0F 0x50 0x54 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x29 0x36 0x80 0xA0 0x70 0x38 0x1F 0x40 0x18 0x10 0x25 0x00 0x99 0xE6 0x10 0x00 0x00 0x1A 0x1C 0x24 0x80 0xA0 0x70 0x38 0x1F 0x40 0x18 0x10 0x25 0x00 0x99 0xE6 0x10 0x00 0x00 0x1A 0x00 0x00 0x00 0xFE 0x00 0x48 0x47 0x54 0x33 0x4A 0x80 0x31 0x38 0x34 0x48 0x54 0x0A 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x41 0x01 0x9E 0x00 0x00 0x00 0x00 0x02 0x01 0x0A 0x20 0x20 0x00 0xA8

 

Can you explain how you're getting the EDID please? I'm trying to catch up with things and are you managing to un-brick the LCD's?

 

That's because Brother @t456 set me up with a modded one that has missing information filled in. I just hotswapped and booted into my Mint Linux installation, swapped the corrupted LCD back after loading Mint and re-flashed it.

Spoiler: Flashed Terminal Output

Code:

owner@M18xR2 ~/EDID/write-edid-master $ sudo ./write-edid.sh 1 SEC5448.bin
[sudo] password for owner:
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x00
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x01
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x02
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x03
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x04
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x05
Writing byte 0xFF to bus 1, chip-adress 0x50, data-adress 0x06
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x07
Writing byte 0x4C to bus 1, chip-adress 0x50, data-adress 0x08
Writing byte 0xA3 to bus 1, chip-adress 0x50, data-adress 0x09
Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x0a
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x0b
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0c
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0e
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x0f
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x10
Writing byte 0x14 to bus 1, chip-adress 0x50, data-adress 0x11
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x12
Writing byte 0x04 to bus 1, chip-adress 0x50, data-adress 0x13
Writing byte 0x90 to bus 1, chip-adress 0x50, data-adress 0x14
Writing byte 0x29 to bus 1, chip-adress 0x50, data-adress 0x15
Writing byte 0x17 to bus 1, chip-adress 0x50, data-adress 0x16
Writing byte 0x78 to bus 1, chip-adress 0x50, data-adress 0x17
Writing byte 0x0A to bus 1, chip-adress 0x50, data-adress 0x18
Writing byte 0xC8 to bus 1, chip-adress 0x50, data-adress 0x19
Writing byte 0x95 to bus 1, chip-adress 0x50, data-adress 0x1a
Writing byte 0x9E to bus 1, chip-adress 0x50, data-adress 0x1b
Writing byte 0x57 to bus 1, chip-adress 0x50, data-adress 0x1c
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x1d
Writing byte 0x92 to bus 1, chip-adress 0x50, data-adress 0x1e
Writing byte 0x26 to bus 1, chip-adress 0x50, data-adress 0x1f
Writing byte 0x0F to bus 1, chip-adress 0x50, data-adress 0x20
Writing byte 0x50 to bus 1, chip-adress 0x50, data-adress 0x21
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x22
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x23
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x24
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x25
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x26
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x27
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x28
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x29
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2a
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2b
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2c
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2d
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2e
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x2f
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x30
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x31
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x32
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x33
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x34
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x35
Writing byte 0x29 to bus 1, chip-adress 0x50, data-adress 0x36
Writing byte 0x36 to bus 1, chip-adress 0x50, data-adress 0x37
Writing byte 0x80 to bus 1, chip-adress 0x50, data-adress 0x38
Writing byte 0xA0 to bus 1, chip-adress 0x50, data-adress 0x39
Writing byte 0x70 to bus 1, chip-adress 0x50, data-adress 0x3a
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x3b
Writing byte 0x1F to bus 1, chip-adress 0x50, data-adress 0x3c
Writing byte 0x40 to bus 1, chip-adress 0x50, data-adress 0x3d
Writing byte 0x18 to bus 1, chip-adress 0x50, data-adress 0x3e
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x3f
Writing byte 0x25 to bus 1, chip-adress 0x50, data-adress 0x40
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x41
Writing byte 0x99 to bus 1, chip-adress 0x50, data-adress 0x42
Writing byte 0xE6 to bus 1, chip-adress 0x50, data-adress 0x43
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x44
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x45
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x46
Writing byte 0x1A to bus 1, chip-adress 0x50, data-adress 0x47
Writing byte 0x1C to bus 1, chip-adress 0x50, data-adress 0x48
Writing byte 0x24 to bus 1, chip-adress 0x50, data-adress 0x49
Writing byte 0x80 to bus 1, chip-adress 0x50, data-adress 0x4a
Writing byte 0xA0 to bus 1, chip-adress 0x50, data-adress 0x4b
Writing byte 0x70 to bus 1, chip-adress 0x50, data-adress 0x4c
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x4d
Writing byte 0x1F to bus 1, chip-adress 0x50, data-adress 0x4e
Writing byte 0x40 to bus 1, chip-adress 0x50, data-adress 0x4f
Writing byte 0x18 to bus 1, chip-adress 0x50, data-adress 0x50
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x51
Writing byte 0x25 to bus 1, chip-adress 0x50, data-adress 0x52
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x53
Writing byte 0x99 to bus 1, chip-adress 0x50, data-adress 0x54
Writing byte 0xE6 to bus 1, chip-adress 0x50, data-adress 0x55
Writing byte 0x10 to bus 1, chip-adress 0x50, data-adress 0x56
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x57
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x58
Writing byte 0x1A to bus 1, chip-adress 0x50, data-adress 0x59
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5a
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5b
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5c
Writing byte 0xFC to bus 1, chip-adress 0x50, data-adress 0x5d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5e
Writing byte 0x4C to bus 1, chip-adress 0x50, data-adress 0x5f
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x60
Writing byte 0x4E to bus 1, chip-adress 0x50, data-adress 0x61
Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x62
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x63
Writing byte 0x34 to bus 1, chip-adress 0x50, data-adress 0x64
Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x65
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x66
Writing byte 0x30 to bus 1, chip-adress 0x50, data-adress 0x67
Writing byte 0x32 to bus 1, chip-adress 0x50, data-adress 0x68
Writing byte 0x53 to bus 1, chip-adress 0x50, data-adress 0x69
Writing byte 0x30 to bus 1, chip-adress 0x50, data-adress 0x6a
Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x6b
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x6c
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x6d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x6e
Writing byte 0xFE to bus 1, chip-adress 0x50, data-adress 0x6f
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x70
Writing byte 0x4D to bus 1, chip-adress 0x50, data-adress 0x71
Writing byte 0x72 to bus 1, chip-adress 0x50, data-adress 0x72
Writing byte 0x2E to bus 1, chip-adress 0x50, data-adress 0x73
Writing byte 0x20 to bus 1, chip-adress 0x50, data-adress 0x74
Writing byte 0x46 to bus 1, chip-adress 0x50, data-adress 0x75
Writing byte 0x6F to bus 1, chip-adress 0x50, data-adress 0x76
Writing byte 0x78 to bus 1, chip-adress 0x50, data-adress 0x77
Writing byte 0x27 to bus 1, chip-adress 0x50, data-adress 0x78
Writing byte 0x73 to bus 1, chip-adress 0x50, data-adress 0x79
Writing byte 0x20 to bus 1, chip-adress 0x50, data-adress 0x7a
Writing byte 0x6C to bus 1, chip-adress 0x50, data-adress 0x7b
Writing byte 0x63 to bus 1, chip-adress 0x50, data-adress 0x7c
Writing byte 0x64 to bus 1, chip-adress 0x50, data-adress 0x7d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x7e
Writing byte 0xB8 to bus 1, chip-adress 0x50, data-adress 0x7f
Writing done, here is the output of i2cdump -y 1 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 4c a3 48 54 00 00 00 00    ........L?HT....
10: 00 14 01 04 90 29 17 78 0a c8 95 9e 57 54 92 26    .????)?x????WT?&
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 29 36 80 a0 70 38 1f 40 18 10    ??????)6??p8?@??
40: 25 00 99 e6 10 00 00 1a 1c 24 80 a0 70 38 1f 40    %.???..??$??p8?@
50: 18 10 25 00 99 e6 10 00 00 1a 00 00 00 fc 00 4c    ??%.???..?...?.L
60: 54 4e 31 38 34 48 54 30 32 53 30 31 00 00 00 fe    TN184HT02S01...?
70: 00 4d 72 2e 20 46 6f 78 27 73 20 6c 63 64 00 b8    .Mr. Fox's lcd.?
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    ................
owner@M18xR2 ~/EDID/write-edid-master $ 

 

i backup my .bin test with this.

https://drive.google.com/file/d/0BxrqgV78chG7TE5rY0NMbzZaUGM/view?usp=sharing