***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.

  1. t456

    t456 1977-09-05, 12:56:00 UTC Moderator

    Reputations:
    1,829
    Messages:
    2,502
    Likes Received:
    1,903
    Trophy Points:
    181
    Beats me. Both HWiNFO and MonInfo can tell you, but think you can guess where they get their data from ... :vbbiggrin: . Your V4 likely says 'unknown'/'undefined', instead of something useful. No idea otherwise (save an excellent calibration result ... ).
    [​IMG]

    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% :vbbiggrin: )
    • spelling (ahem :vboops: )
    It's based on lubuntu, btw (try it sometime). This choice was made after excessive trial and error detailed and exhaustive prior research, seeing as it met all criteria:
    1. live -> no install required
    2. persistent -> changes stick, even after reboot
    3. dual boot uefi+legacy -> in case of impossibility to switch
    4. small -> downloadable(-ish)
    [​IMG]

    Instructions to write to stick:

    [​IMG]
    • 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 :vbtongue: ).
    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 :vbsmile: !
     
    Last edited: Jul 30, 2016
  2. RODBORA

    RODBORA Notebook Enthusiast

    Reputations:
    0
    Messages:
    12
    Likes Received:
    8
    Trophy Points:
    6
    @t456, I used the first version of this, followed the instructions and now my notebook its working perfectly. Congratulations and thank you so much to put all together in the same place. The instructions are very clear. Well done!
     
    t456 and Mr. Fox like this.
  3. MahmoudDewy

    MahmoudDewy Gaming Laptops Master Race!

    Reputations:
    465
    Messages:
    1,611
    Likes Received:
    696
    Trophy Points:
    131
    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
  4. Rimas

    Rimas Notebook Geek

    Reputations:
    0
    Messages:
    80
    Likes Received:
    36
    Trophy Points:
    26
    Just a curious finding on GeForce Wiki page:
    "Nvidia proprietary GeForce driver version 358.09 beta received support for the DRM mode-setting interface.[25]"

    The "DRM mode-setting interface" part is linked to this:
    "In order to work properly, a video card or graphics adapter must set a mode —a combination of screen resolution, color depth and refresh rate— that is within the range of values supported by itself and the attached display screen. This operation is called mode-setting,[19] and it usually requires raw access to the graphics hardware —i.e. the ability to write to certain registers of the video card.[20][21] A mode-setting operation must be performed prior to start using the framebuffer, and also when the mode is required to change by an application or the user."

    Could it be that the driver allows a bit too much control of the graphics hardware nowdays that gets trashed by certain 3rd party software?
     
    Rundll32, Kade Storm and Prema like this.
  5. woodzstack

    woodzstack Alezka Computers , Official Clevo reseller.

    Reputations:
    1,196
    Messages:
    3,478
    Likes Received:
    2,573
    Trophy Points:
    231
    I was just about to say, when I was executive IT support for GSK, I had to do this sometimes...and by sometimes I mean like at least once a week in some cases.
     
    The Strategist likes this.
  6. Mr. Fox

    Mr. Fox Undefiled BGA-Hating Elitist

    Reputations:
    27,354
    Messages:
    34,456
    Likes Received:
    53,931
    Trophy Points:
    931
    I think this might have something to do with the driver that Linux loads using the Live distro and whether or not the default driver is reliant on a good EDID. I had this same problem on the Panther until I used HDMI display output, and that resolved the black screen. Using DVI the output was a black screen. If you haven't already, you might try HDMI and see if that works. Maybe @t456 knows something technical about that. Based on my uneducated wild guess, HDMI output doesn't care about having a good EDID and the the others may require it. The other thing I did was change the BIOS to Legacy mode, which will not work on Alienware laptops equipped with Maxwell GPU(s) unless you have the Alienware 18 with the latest BIOS (A12) because of the 8-beep Maxwell incompatibility problem. I used the older Linux tool kit provided by @t456 and it would not boot in UEFI mode. Sounds like his new tool kit resolved that.
     
    MahmoudDewy likes this.
  7. MahmoudDewy

    MahmoudDewy Gaming Laptops Master Race!

    Reputations:
    465
    Messages:
    1,611
    Likes Received:
    696
    Trophy Points:
    131
    Actually currently my new screen is working. I am trying to have this ready as fail safe for when the screen gets corrupted :(
     
  8. Tulius

    Tulius Notebook Consultant

    Reputations:
    5
    Messages:
    242
    Likes Received:
    76
    Trophy Points:
    41
    A friend of mine got the screen bricked today with 8 beeps no boot... it seems Windows 10 isn't the culprit here because he used Windows 8.1 with EVGA Precision 16, played some games and after a windows update the notebook(M18X-R1 880M installed) got the 8 beep hell. I know that with the Alienware 18 is easier to use the EDID linux distro to flash the screen because it accepts to boot with a external screen but with the old R1 and R2 that's not a option so what can I do to help him recover the screen?
     
  9. Mr. Fox

    Mr. Fox Undefiled BGA-Hating Elitist

    Reputations:
    27,354
    Messages:
    34,456
    Likes Received:
    53,931
    Trophy Points:
    931
    Put your M18xR2 screen on his M18xR1 to get it past the 8-beeps, then disconnect it and reconnect his after you reach the Linux desktop. Flash it and his troubles are over as long as he doesn't let it get bricked again. Either do it like that, or take his screen off and hot-swap it to the connection on your motherboard and flash it on your machine instead of his. That way all you need to take off of yours is the bezel around the keyboard. Just disconnect your LVDS cable and lay it back toward the keyboard to make room for his to plug in. Stand his screen up in front of yours with his display hinges next to yours. This is assuming you can actually boot the Linux EFI version with 980M running in UEFI mode with your R2.
     
    Tulius and t456 like this.
  10. m11kkg

    m11kkg Notebook Consultant

    Reputations:
    7
    Messages:
    130
    Likes Received:
    33
    Trophy Points:
    41
    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
     
    PC GAMER and Rundll32 like this.
Loading...

Share This Page