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

Thanks for your reply I would do that with pleasure but not sure how too , not even sure how to insert a picture from my laptop to my post here ..sorry more hardware oriented hahaha , I have a picture on my desktop but how do I upload to here ? ....Cheers
'

 

@murphey1965 Located on page 150 of this thread.

Spoiler: Read this

 

I Really appreciate the work involved , but just looking at what you have done is impressive but I really have no clue even where to start , sorry but when it comes to things like this my mind is a blank , can not believe it is so complicated just to rewrite the EDID , I did download it all and put it on a usb stick and that's about as far as I got ...really gutted its so complicated was really hoping for a flashing tool of sorts what a bummer :-(

 

Once you do it youll get used to it.. new terminology, using a command line looks daunting to many users no doubt.. but this is no ordinary problem either. Only thing i could suggest is asking mr fox or t456 and pay them to do it for you?

Sent from my SM-G900F using Tapatalk

 

Yeah your right I have no problem paying someone but I am in the UK at the moment , so asking Mr Fox to do this or t456 how can I do that ? remotely ? I have found on the forums a good EDID file to replace my corrupted one but its just the issue of actually writing it to the panel ..you are all great guys but I have never done anything like this , I mean with the Linux I have on my usb stick do I need to boot from that ? , I just didn't want to end up making things worse hahahaha

 

I take it you had Windows 10 ready updates that were already downloaded and installed on your Windows 8.1 laptop? (You'd know because of that little white Windows icon in the bottom right tray that says something about a Windows 10 upgrade)

Also, for posterity - Did you have stock BIOS and stock VBIOS? What Alienware model (I'm guessing M18 since you can use an external monitor to boot) and what GPU(s)?

 

Nope, he has an Alienware 17 (which he refers to as an "R5") according to what he posted.

See post # 1578 for details on Linux flashing. You have no idea how lucky you are to be able to boot from an external monitor. Most of us find that does not work.

 

Hi Mr Fox , yes sorry I have Alienware 17 with standard bios 14 and 980m with prema vbios , the weird thing is when I boot without connecting my hdmi it beeps 8 times , when I plug in the hdmi the initial boot screen is blank on the monitor display but not on the tv display , and then when in windows both come on and I can actually unplug the hdmi and run directly from the laptop screen , but in aida 64 my monitor comes up as Monitor Name NVIDIA Virtual Audio Device [NoDB] and this was a fresh install of windows 8.1 , no 10 on this system and I blocked all updates relating to 10 . and in device manager it comes up as generic non pnp monitor ?

 

Microsoft allegedly pushed through another Windows 10 ready update besides the ones you blocked.
That was done in the last week or so according to what I read.

See http://tech.slashdot.org/comments.pl?sid=8136977&cid=50683655

 

Yes, it's because you have the 980M running in pure UEFI mode. That doesn't allow my M18xR2 to boot from HDMI in pure UEFI mode for some reason. Maybe it's something about 780M that's different. @Daniel1983 was able to boot from HDMI with his LCD bricked on his AW18 as well. That machine has 880M and it's running in pure UEFI.

So, all you need to do is boot from a Linux installation and run the commands to flash a good EDID. I have a dedicated Mint Linux installation that replaced Windows 8.1 on my M18xR2 mSATA drive, but a bootable USB stick will work beautifully. That's what I started with.

 

So.... i have the linux installation image, an m-sata ssd to install to, and one of the old LCD messed up ready to start. Beside a dell U2412 as an external display .
Do you think an M18x R2 (680M) wont install linux in full legacy mode? and it will keep up the 8 beeps nonsence??
Opinions?
Thx.

 

Could someone with a currently bricked display try this, possibly by creating the override key in the registry with the proper edid. It is a possible in windows solution to rewrite the edid and could be a possible partial explanation on how this is being rewritten:
https://msdn.microsoft.com/en-us/library/windows/hardware/jj133967(v=vs.85).aspx

@Mr. Fox , @t456 , @Prema , and anyone else that wants to attempt this!

Edit: I understand, if you cannot get into windows, you cannot do this from within Windows. But maybe creating an override .inf and seeing if this allows for use of windows without the trigger causing a rewrite after the eeprom has been reflashed. Test to see if it works. Test to see if EVGA still flips it, etc. This may be the way to keep it from doing what it is doing in the future and allow users to use whatever programs they care to without fear.

 

It won't work. It's shadow copy of in-display EDID, not the "stream" to the original EDID

 

NICE. Star Wars battlefront beta requires 355.60 GeForce drivers. Any way to fake driver version?

 

I guess I'll be playing that on my desktop computer. I can't even get them to send my my order anyway. On my second order now after the first one got cancelled.

 

Read it again. This explains how display manufacturers can flash eeprom through Windows. Not the normal registry key entry...

Edit: I was wrong, you were right. But there is a chance, because this creates the new reference, it will be corrupted instead of the actual edid on the eeprom. What was previously tried was enabling the edid of the display registry entry and copying that entry over the bad_edid registry key. The override may work since it redirects the programs to that key.

 

After reading your link, that sounds like it could work - could be any easy fix!?

 

It may or may not work because the problem is occurring during POST. If Windows can overwrite the EEPROM on the LCD with a good EDID it will work. If not, then it will not work. Changing the EDID in Windows won't help if the EEPROM still has the wrong EDID and the machine fails to POST with 8 beep.

If Windows is writing to the LCD EEPROM, then this may be the scenario that Windows 10 and Windows 10 readiness updates may be using to cause the problem to begin with. If so, getting it to work in reverse might be a solution. If that is the case, Micro$loth is going to need to correct it in Windows Updates to prevent it from happening to more people.

https://msdn.microsoft.com/en-us/library/windows/hardware/jj133967(v=vs.85).aspx

I've been using this INF in an effort to stop the EDID corruption and it hasn't helped. Nothing helped so far except removing EVGA Precision X. The LCD bricked on my M18xR2 and AW18 BEFORE I had installed EVGA Precision X. However, it may also be that EVGA Precision X is using exactly the same process that Windows 10 does to cause the same end result. Wouldn't that be interesting... unrelated causes with the same outcome, using the same vehicle to create the problem. Interesting. @t456 - what say you, Brother?

Spoiler: M18xR2 SEC5448 Display INF content

Code:

; INF file generated by Monitor Asset Manager (2.70.0.989), 10/8/2015
; Copyright (c) 1995-2013, EnTech Taiwan.
; Internet: http://www.entechtaiwan.com

[Version]
Signature="$WINDOWS NT$"
Class=Monitor
ClassGUID={4d36e96e-e325-11ce-bfc1-08002be10318}
Provider=%MFG%
DriverVer=10/8/2015, 1.0.0.0
;CatalogFile=YourSignedCatalogFile.cat

[DestinationDirs]
DefaultDestDir=23

[SourceDisksNames]
1=%DISC%

[SourceDisksFiles]
;YourColorProfileFile.icm

[Manufacturer]
%VENDOR%=EDID_OVERRIDE,NTx86,NTamd64

[EDID_OVERRIDE.NTx86]
%PRODUCTID%=OVERRIDDEN-EDID.Install, MONITOR\SEC5448

[EDID_OVERRIDE.NTamd64]
%PRODUCTID%=OVERRIDDEN-EDID.Install.NTamd64, MONITOR\SEC5448

[OVERRIDDEN-EDID.Install.NTx86]
DelReg=DEL_CURRENT_REG
AddReg=OVERRIDDEN-EDID.AddReg, MODE1, DPMS
CopyFiles=OVERRIDDEN-EDID.CopyFiles

[OVERRIDDEN-EDID.Install.NTamd64]
DelReg=DEL_CURRENT_REG
AddReg=OVERRIDDEN-EDID.AddReg, MODE1, DPMS
CopyFiles=OVERRIDDEN-EDID.CopyFiles

[OVERRIDDEN-EDID.Install.NTx86.HW]
AddReg=OVERRIDDEN-EDID_AddReg

[OVERRIDDEN-EDID.Install.NTamd64.HW]
AddReg=OVERRIDDEN-EDID_AddReg

[OVERRIDDEN-EDID_AddReg]
;Base EDID
HKR,EDID_OVERRIDE,"0",0x01,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,0xFC,0x00,0x4C,0x54,0x4E,0x31,0x38,0x34,0x48,0x54,0x30,0x32,0x53,0x30,0x31,0x00,0x00,0x00,0xFE,0x00,0x4D,0x72,0x2E,0x20,0x46,0x6F,0x78,0x27,0x73,0x20,0x6C,0x63,0x64,0x00,0xB8

[DEL_CURRENT_REG]
HKR,MODES
HKR,EDID_OVERRIDE
HKR,,MaxResolution
HKR,,PreferredMode
HKR,,DPMS
HKR,,ICMProfile

[DPMS]
HKR,,DPMS,,0

HKR,,PreferredMode,,"1920,1080,60"
[MODE1]
HKR,,MaxResolution,,"1920,1080,60"

[OVERRIDDEN-EDID.AddReg]
HKR,"MODES\1920,1080,60",Mode1,,""

[OVERRIDDEN-EDID.CopyFiles]
;YourColorProfileFile.icm for non-sRGB displays

[Strings]
MFG="Dell"
DISC="Monitor EDID Override Installation Disk"
PRODUCTID="Samsung LTN184HT02S01 (SEC5448 EDID Override)"
VENDOR="Samsung"

 

Unless it is known already, making sure Windows isn't changing something upon shutting down would be another clue as to WHEN exactly the EDID is being modified as well.

Sent from my SM-N900P using Tapatalk

 

Ah, yes, of course (I didn't twig!), it's happening during post! Makes it less likely to be a fix then, but I see what you mean by 'reverse' - that it might prevent EDID corruption if implemented before problems occur.

 

I had already suggested that we might try and modify the registries EDID and @t456 said that it wouldn't matter. This thread is so big that I can't find the post to quote, but he gave a reason why that I can't remember that made sense.


Sent from my iPhone using Tapatalk

 

It does not matter. I already tried that.

 

Thanks for the time to reply I know you are a busy man , but that's the issue I have ..I installed lubuntu I downloaded through a link in this forum to a bootable flashdrive , I can f12 and then it loads up and then what my god I sound like an idiot its just like a operating system and I have no idea where to find a good EDID for my lg Display panel or how to flash it through lubuntu...such a noob when it comes to this sort of thing but I am willing to give it a shot... unfortunately need instructions for an idiot maybe something like an ''idiots guide to flashing a corrupted EDID'' maybe then I could possibly do it...maybe

 

Well, I'll be the first to admit I am an ignoramus when it comes to Linux. Anything I know (which isn't much) I have needed to figure out, mostly through trial and error, and the internet is not much help. Seems most people don't know what they don't know. Some of what you find assumes the reader is already a Linux expert, much of it is outdated and obsolete, and some things just flat-out don't work, LOL.

Look at the "Instructions" file that @t456 provided in the download package for step-by-step instructions, and look at what I posted here to supplement those instructions with some visual examples. I believe he may have already provided a good EDID for your display as well. It is very easy to do, but since everything is done in a terminal, syntax means the difference between success and an error message, capitalization matters (although in Windows it does not), permissions (sudo) and doing things in a precise sequence matters.

Once you figure it out, you'll be like, " wow, that was so easy" and you'll also have a better understanding of why Windows dominates the computer world. Linux is not an OS for the masses, and probably never will be, because it requires too much thought and effort to do things, and the average Joe Schmoe is absolutely not interested in anything beyond a point and click experience... or, swipe and tap in the context of all the pathetic tablet and touch-screen crap that surrounds us.

Edit: ignore the part about snipping the wire for pin #5 on the LVDS cable. That doesn't do anything useful. We thought it might, but it does not write protect the display.

 

Whew! Been away for a couple weeks in work-crunch time, but found a few minutes (well, okay, almost an hour) to try to catch up here. Not much new I can contribute (yep, being in Legacy boot prevents booting with external monitor via HDMI or VGA out) - though I will note the first page lists cards affected as 780, 880 and 980. I"m not quite that cool - had the same issue while dual-wielding 680s, but given the overall architectural similarities I don't think that really adds much. I would be interested in chatting you privately, MrFox, if you're still willing to discuss arrangements for transport of a patient, but I can't seem to find where the PM system is around here. ^^: Glad to hear you're having more success in at least immunizing a patient once they've been resuscitated.

Looks like my overall plan is going to have to be:

1) Repair monitor EDID
2) Gain access to BIOS, bite the bullet and switch to pure UEFI-boot to at least allow it to POST if the issue recurs
3) Remove potential triggers (I think I did have EVGA Precision installed, though if so it was from a previous attempt at manually setting fan speeds that didn't work and I never bothered to uninstall)
4) Sacrifice two chickens and a goat to the appropriate Linux Daemon in anticipation of trying to get a dual-boot working with grub and UEFI *twitch*

 

@Mr. Fox- So since all of these problems are rooted to Windows 10, you think Steam OS will be fine? It's right around the corner and I just want a working computer that won't commit suicide when it restarts.
Have you been able to recreate an EDID corruption with Linux? I figure if Linux is fine, then Steam OS will be fine too seeing how Steam OS is just a fancier Linux.


Sent from my iPhone using Tapatalk

 

SteamOS is modified Debian

 

Debian uses the Linux kernel.
https://www.debian.org/intro/about

Sent from my iPhone using Tapatalk

 

Okay Thank you , I don't feel so stupid now , well maybe a bit , regarding the 1gb download he does state that there is a folder on there called EDID but when I extracted it to the usb stick there is no folder of that name I could find

Thanks Mr Fox , will give it a shot , got into Linux followed the instruction's but when I got to sudo sensors detect ...nothing was found when I selected 12c/SMbus selected yes on all the probes but came back with nothing ...so any ideas ....and just one thing as I am using my hdmi tv to do this on I was worried about writing the EDID file to the wrong display how do I make sure I am writing the file to the correct display...cheers

 

PS4 uses a modified version of linux

 

Uh, really sherlock ? I was trying to tell you that debian is linux and steamOS is modified debian.


@murphey1965 I think best way to do it is to download EDID from random display and check inside if it says SECxxxx. If yes then this display is Alienware one.

 

emmm...... AFAIK Orbis OS (the PS4 OS) is based on FreeBSD 9.0, not linux

 

Yes it's based on FreeBSD, not linux.

 

Unlikely; clock switching has been around for quite a while and shouldn't affect the edid's eeprom pins. That is ... unless it's crosstalk after all. If it is a crosstalk issue then it'll be tied-in with the display wires; higher frequency, more data and/or higher voltage to backlight. This might be checked by running:

• low resolution
• stock refresh rate
• low brightness (hm ... the '10 = higher brightness' thingy? *)

Using those settings will limit traffic over the display cables wires to a minimum and, thus, crosstalk potential as well.

*) Side-note; higher brightness can be achieved by increasing vcom value (which happens to be stored on the edid eeprom). Drawback of vcom adjustment (low or high) is increased flicker.

Absolutely.

Absolutely.

Unlikely. But GPU access in itself; yes. Edid eeprom control can be handled directly by the gpu.

First inkling says 'no', but thinking of crosstalk and MXM ...

Actually, MXM does facilitate direct gpu->edid interface. And all non-Optimus Clevos have implemented it like that, whereas the Optimus systems have their MXM edid pins disconnected and all edid control is handled over the Intel PCH (chipset).

Spoiler: Clevo edid control, Optimus vs. non-Optimus

So, presumably, all affected systems have direct ' dGPU->edid' access. Either when enabled via a bios switch (AW) or no switch at all (Clevo). Safe to say the edid corruption takes place via the nvidia dGPU, whether it's really the nvidia driver doing so or a non-nvidia driver or process (hidi2c?).

Yes. We've confirmed the incorrect wiring of the edid eeprom on at least two of the affected panels. Good photos and analysis of the other displays' pcbs could check that across the board.

Code:

pnp id  notes   interf  panel nr.       edid eeprom         eeprom ok?
------- -----   ------  -------------   ------------------- ----------
AUO219D !       LVDS    B173HW02 V1     ?                   ?
CMO1720 !       LVDS    N173HGE-L11     ?                   ?
LGD02DA !       LVDS    LP173WF1-TLB3   ?                   ?
SDC4C48 !       LVDS    LTM184HL01-C01  ?                   ?
SEC5044 !?AW    eDP     LTN173HT01-301  Winbond 25X20BLNIG  no!
SEC5044 !?AW    eDP     LTN173HT02-D**  Winbond 25X20BLNIG  no!
??????? A       eDP     LTN173HT02-D02  "" ?                ?
SEC5044 A       eDP     LTN173HT02-P01  "" ?                ?
SEC5044 A       eDP     LTN173HT02-T01  "" ?                ?
SEC5448 !       LVDS    LTN184HT02-S01  ?                   ?

So ... if anyone can make some photos of any of the missing "?" lcds then we'll know what's what regarding the panel's culpability in this mess.

Yes, it seems that way.

 

Agree, think we have two most-likely suspects atm:

1. Edid eeprom's wp-byte flipped by 10 (or 10-ready).
2. Nvidia vbios eeprom's spare storage space written with active code or hook (possibly by 10/10-ready).

These respective checks apply:

1. Display swap ought to fix this, provided the new OS isn't 10 or 7/8.x with 10-ready updates.
2. MXM swap should prevent recurrence and, again, no 10 or 10-ready.

Yes, checking those updates is crucial. Bit hard to do without redistributables, though. We'll want to limit search to August 2nd or older, seeing as that's when your problems started.

That vbios eeprom is the factor that stays, since a flipped wp-byte on the edid eeprom will be undone when swapping in a new display. Or, at least, one that came from a non-10/non-10-ready system.

If anyone cares to ship me their affected nvidia MXM; send a pm. Will unsolder vbios eeprom, read entire content, resolder and ship back (will check it's running before shipping). You may also piggyback a bricked lcd along with the mxm; will fix the display and we'll have the hidden vbios code as well (if, indeed, there is any).

 

Sounds like you found the EDID folder in the Home folder.

Try running these commands in a Terminal.

If the result for address 0 (first command) is a bunch of X marks instead of numbers, try 1. If address 1 returns X marks, try 2. When you actually see the EDID displayed you will know that is the correct address on the SMbus for the LCD. Think of this as you would GPU0 and GPU1 in a laptop with dual GPU. Each GPU has a different "address" just as all things on the SMbus have a unique address. The EDID won't be found if you try to decode the EDID at an address where no LCD panel is located, so it will give you a bunch of X marks where you would normally see valid hex code.

So, once you know the number (in my case 1) that identifies where the LCD is found on your SMbus, then the command "sudo ./write-edid.sh 1 SEC5448.bin" should write the correct EDID to your EEPROM. Note: Substitute SEC5448.bin for the name of your EDID .bin file and take special note that letter case ( capitalization) matters with Linux. If you tell it to write ABC.BIN and the file is actually named abc.bin it will give an error message about not finding that file in all upper case because those are two different files names under Linux. It has to be exact under Linux, whereas Windows does not care about upper and lower case.

As the EDID is being written you should see this type of output in the terminal window (as opposed to an error message).

Code:

mint@mint ~/Downloads/write-edid-master $ sudo ./write-edid.sh 1 SEC5448.bin
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 0xFE to bus 1, chip-adress 0x50, data-adress 0x5d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x5e
Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x5f
Writing byte 0x47 to bus 1, chip-adress 0x50, data-adress 0x60
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x61
Writing byte 0x33 to bus 1, chip-adress 0x50, data-adress 0x62
Writing byte 0x4A to bus 1, chip-adress 0x50, data-adress 0x63
Writing byte 0x80 to bus 1, chip-adress 0x50, data-adress 0x64
Writing byte 0x31 to bus 1, chip-adress 0x50, data-adress 0x65
Writing byte 0x38 to bus 1, chip-adress 0x50, data-adress 0x66
Writing byte 0x34 to bus 1, chip-adress 0x50, data-adress 0x67
Writing byte 0x48 to bus 1, chip-adress 0x50, data-adress 0x68
Writing byte 0x54 to bus 1, chip-adress 0x50, data-adress 0x69
Writing byte 0x0A to bus 1, chip-adress 0x50, data-adress 0x6a
Writing byte 0x20 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 0x00 to bus 1, chip-adress 0x50, data-adress 0x6f
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x70
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x71
Writing byte 0x41 to bus 1, chip-adress 0x50, data-adress 0x72
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x73
Writing byte 0x9E to bus 1, chip-adress 0x50, data-adress 0x74
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x75
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x76
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x77
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x78
Writing byte 0x02 to bus 1, chip-adress 0x50, data-adress 0x79
Writing byte 0x01 to bus 1, chip-adress 0x50, data-adress 0x7a
Writing byte 0x0A to bus 1, chip-adress 0x50, data-adress 0x7b
Writing byte 0x20 to bus 1, chip-adress 0x50, data-adress 0x7c
Writing byte 0x20 to bus 1, chip-adress 0x50, data-adress 0x7d
Writing byte 0x00 to bus 1, chip-adress 0x50, data-adress 0x7e
Writing byte 0xA8 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 fe 00 48    ??%.???..?...?.H
60: 47 54 33 4a 80 31 38 34 48 54 0a 20 00 00 00 00    GT3J?184HT? ....
70: 00 00 41 01 9e 00 00 00 00 02 01 0a 20 20 00 a8    ..A??....???  .?
80: ff ff ff ff ff ff ff ff ff 01 ff ff ff ff ff ff    .........?......
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
mint@mint ~/Downloads/write-edid-master $

 

@t456- do you live in the US? If so, what part of the country? I may be able to ship mine seeing how it's not finding any other use haha.


Sent from my iPhone using Tapatalk

 

@t456 I've got a 780M and display that I could send for you to check as well, since Nvidia is being 100% uncooperative now.

 

they're in the netherlands i think from sending my old screen to them.

 

Holly shipping lol


Sent from my iPhone using Tapatalk

 

$60 CAD for like 8 days isn't too bad considering i wasn't asking for anything on the screen....aka free screen.

 

There is, only it hasn't been tried so far. And surely you mean write protect . Mr. Fox tried read(+write) protecting the display (by clipping the edid's display cable wires); that didn't pass 'Go', unfortunately.

Could you try making an export of that edid? Will be very useful for research.

Now THAT is interesting. There's two explanations, afaics, one prosaic the other far more serious:

1. Edid pnp id has been corrupted (and aida uses that).
2. Device enumeration has been changed by Windows 10 permanently (via vbios write?).

There's also something interesting regarding the HD 7970M spec. sheet posted earlier:

Spoiler: Clevo P375SM-A's MXM master connector and HD 7970M MXM

That's just ... really weird, peculiar, quaint and so on ... ??? The P37*-*M systems should have serious issues when using audio+AMD gpus and the Clevo x7200 and P570WM should see strange behaviour when using SPDIF+AMD ('HDA' non-connected here).

True enough. Difficulty is ' how' to read the edid from within Windows. Tried the EnTech tools; all failed. Even RWE didn't work ... soldering wires directly to the eeprom; yes, but ...

The stick is 'live' and persistent. That means no need to install (or hdd, even) and any changes are written to the stick itself. The 'EDID' folder is hidden/embedded in a single 'persistent' file that changes dynamically while using/accessing the stick. So ... let's say you join a wifi network and enter password; shutdown, reboot and that password will be remembered (pw has been written to the stick).

No; Europe. Thanks for the offer, though . Really curious about that vbios eeprom ... perhaps we'll find the NSA hiding there . Seriously ... they have and are doing that right now .

 

Myes, still have to do something with that ... kinda busy though; work backlog. Tried to write edid on the Clevo via write-edid.sh; no go (black display on good screen), so need to resort to programmer.

 

I just heard back from a Nvidia rep, and while it isn't good news it is something (this is regarding my request for information on what they found out):

"Unfortunately I cant comment on that at this time, it doesn't involve us or our drivers but I cant comment on what the issue is right now since its with other peoples software/content.

All I can say is that the main threads talking about this are accurate in the piece of software that caused this issue."

 

They really are covering their asses. This clearly has just as much to do with them as it does with Micro$oft. I intend on keeping that post bumped on their website till I get banned. Completely unexceptionable behavior. They really aren't the company they used to be. I'm amazed that the media hasn't seen that. It's got like 40,000 views last I checked.


Sent from my iPhone using Tapatalk

 

Windows 10... the Redmond Mafia... just as we all suspected from the beginning (as if it wasn't totally obvious by the sequence of events, LOL). Hopefully, Alienware can undo what they did or convince them to fix it. Otherwise, we are all screwed because Micro$haft absolutely does not care about customers. That's obvious by the worthless crap operating systems they have produced after Windows 7. Almost everything they do is stupid and half-butted. Other than my sucky 780M SLI throttling problem, NVIDIA drivers never broke anything until Windows 10 cancer entered my life.

On a positive note, I'm a week into no EDID corruption without EVGA Precision X installed now. Guess I won't be using that any more. I am now triple-booting Windows 7, Windows 8.1 and Mint Linux.

 

So would convincing @prima or @Slv7 to write zeros to the rest of the vBios help overwrite whatever nonsense is causing the corruption?


Sent from my iPhone using Tapatalk

 

The problem is not the vBIOS or the extra space on the chip. From what I understand, NVFLASH wipes out everything on the chip with the -6 part of the command.

Those that had bricked displays in the absence of EVGA Precision X may be able to recover and carry on normally by flashing the display if EVGA Precision X is not installed. I have not experienced any issues under Windows 7 or 8.1 without it installed. In another week or so I am going to test an older version of EVGA Precision X to see if the bricking problem returns. For now I am going to simply enjoy not having to reflash my LCD once or more every day.

 

Is your system fully updated to the Windows 10 Ready point and still not bricking without Precision X? If not, how far did you update?


Sent from my iPhone using Tapatalk

 

that's what i thought: so there should be no residual traces of any vbios corruption with a eeprom flash.