wxEDID - A tool for modifying EDID data on Linux

[andoru]

Initially I started this thread asking for help on a resolution problem, but after a while, tomazzi came up with an utility that could help modify EDID data, so I decided to modify this thread to post links for it:
________________________________________________________________________________________________________
Screenshots:


Sources

Description:

Code: Select all

wxEDID is a wxWidgets - based EDID (Extended Display Identification Data) editor.
This is an early stage of development, allowing to modify the base EDID v1.3+ structures. Support for EDID extensions is planned, but not yet implemented.
Besides normal editor functionality, it currently allows to export to and import EDID data from text files (hex format) and also to save the structures in a human-readable text format.

Changelog:

Code: Select all

#Change log for wxEDID

2014.06.12
   - released v0.0.8:
   - Fixed: cea_adb_cl::init() all SAD instances are referencing data from SAD instance 0:
            missing data pointer incrementation.
   - Fixed: DTD_Ctor_Recalc() returns uninitialized rcode.
   - Fixed: Reparse(): force number of valid edid blocks if "Ignore EDID Errors" is enabled.
            This allows to export faulty blocks, which are otherwise dropped.

2014.06.11
   - released v0.0.7:
   - Added: CEA-861 support (as first extension block)
   - Added: Value selector menu: some CEA-861 fields contains indexes, not actual values.
   - Fixed: import/export/load/save functions are now aware of extensions.
   - Added: Menu Options: Ignore EDID Errors -> allows to ignore minor EDID erros and to view the
            data anyway.
   - Added: Menu Options: Recalc Checksum
   - Fixed: DTD "virtual" screen is resized on Frame size change.
   - Cleanup: some field handlers replaced with generic funcions.

2014.04.23
   - released v0.0.6:
   - Added: X11 ModeLine viewer on DTD constructor panel (quick patch)

2014.04.19
   - released v0.0.5:
   - Added: DTD constructor panel.
   - Change: field handlers can now use uint var as alternative i/o value.
   - Fixed: Disable save/export/save_as menu items until EDID buffer is loaded.
   - Fixed: ParseGroups() didn't checked group init() rcode.
   - Fixed: Bad conversion of mfc_id to PNP_ID (on write, misuse of temporary pointer)
   - Fixed: EDID checksum field handler replaced with generic ByteVal(), which is more type-safe
   - Fixed: EDID prod_id field handler: require "0x" prefix for EF_HEX type field.
   - Fixed: descriptions and order of some fields: some descrptions were still buggy and fields
            order was not necesarily readable.
   - Cleanup: removed unused fn rdUByte() and wrUByte()

2014.04.09
   - released v0.0.4:
   - Fixed: memory leak in edi_grp_cl - missing destructor, edi_dynfld_t fields
            were not deleted on exit/reparse;
   - Fixed: some fields descriptions were inaccurate or buggy.
   - Added: AST: Additional Standard Timings Descriptor support (it was missing by mistake)

2014.04.08
   - Initial release v0.0.3. Code still needs cleanups and
     there are many features left to implement, but the base
     editor is tested and working.

2014.03.18
   - Project started: GUI code & layout, EDID definitions

________________________________________________________________________________________________________

Details of my earlier issues:
________________________________________________________________________________________________________

I've installed read-edid recently to get edid data from my monitor (as it has it's refresh rate and resolutions detected incorrectly). The first time when I tried to use this utility (get-edid) it failed on me. I tried contacting the author of the utility, and he mentioned that it failed because if fell back on the VBE interface, and that usually doesn't work for detecting EDID data.
He told me that I might need to modprobe i2c-core as root, build some new modules, install the right package, "or something similar".
I tried to issue 'sudo modprobe i2c-core' but that doesn't return anything, nor does it actually load i2c-core as get-edid still uses VBE.
I also tried to look for packages related to i2c, all I found was i2c-tools, but seems it didn't help with anything, nor do I know what's the command to launch it.
Sorry for my n00bish questions.

[tomazzi]

It would be nice to know what's your gfx card and the monitor.
Generally You don't need to read EDID if You have correct drivers installed (then it's possible to just use 'xrandr --prop' to get EDID data). If You don't have drivers for Your exotic gfx card, then just try different modes in xorg.conf (vbeinfo from GRUB might be helpful) to get best results.

Regards.

[andoru]

Thanks for your answer.
Video card: GeForce 6600 GT and Philips 193V5L as monitor.

'xrandr --prop' returns:

Code: Select all

Screen 0: minimum 8 x 8, current 1368 x 768, maximum 4096 x 4096
VGA-0 connected primary 1368x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
	EDID: 
		00ffffffffffff00410ccdc04e470000
		291701036e2917782a0cc5a45750a128
		0d5054bd4b00818081c0010101010101
		010101010101662156aa51001e30468f
		33009ae61000001e000000ff00554b30
		31333431303138323534000000fc0050
		484c2031393356350a202020000000fd
		00384c1e530e000a2020202020200013
	SignalFormat: VGA 
		supported: VGA
	ConnectorType: VGA 
	ConnectorNumber: 0 
	_ConnectorLocation: 0 
   1368x768       60.0*+
   1280x1024      75.0     60.0  
   1280x720       60.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   640x480        75.0     72.8     59.9  
DVI-I-0 disconnected (normal left inverted right x axis y axis)
	SignalFormat: VGA 
		supported: VGA
	ConnectorType: DVI-I 
	ConnectorNumber: 1 
	_ConnectorLocation: 1 
TV-0 disconnected (normal left inverted right x axis y axis)
	SignalFormat: unknown 
		supported: unknown
	ConnectorType: TV 
	ConnectorNumber: 2 
	_ConnectorLocation: 2 
DVI-I-1 disconnected (normal left inverted right x axis y axis)
	SignalFormat: TMDS 
		supported: TMDS
	ConnectorType: DVI-I 
	ConnectorNumber: 1 
	_ConnectorLocation: 1 

But it's not correct, the native resolution should be 1366x768 not 1368x768 (I have never heard of the latter)
Also the sync rates that are written in xorg.conf are incorrect, plus that I've seen somewhere my monitor being listed as CRT when in fact it's a flatpanel LCD.
Admittedly the driver I'm using isn't working as it should (and that's in another thread that I started before this one), but it's a (non-free) driver recommended by nVidia for this card.
Not sure how to get to vbeinfo.
Also I tried to edit xorg.conf to add modelines that were in the nouveau driver (which properly detected my monitor's resolutions). But that ended up with "double free or corruption" errors when starting slim. I'm not sure if it's a syntax mistake I made or there's something weird going on.
Here's the xorg.conf that I made: http://pastebin.com/4MkmpPsW

[tomazzi]

I can't see anything wrong in the refresh rates - they look completely normal (for LCD).
Your monitor has only VGA connector (according to online specs), so it uses VGA-compatible signals, and the VGA-0 connector on the gfx card. It is also possible, that noveau will report more corect EDID data regarding the resolution, because nvidia has long tradition in making bugs in their randr implementation...
Read this to find out how to resolve the problem.

Regarding Your xcorg.conf - it seems to be correct, but it's sufficient (and sometimes it's better) to provide only one, native resolution for the Monitor/Screen.

I've mentioned vbeinfo , because it can help in case if no drivers are available for the gfx card and vesa is used as fallback. It won't help You in this case. Of course, just out of curiosity You may check the resolutions reported by vbeinfo: press ESC on Grub2 boot menu/splash, then press 'c' and type vbeinfo.

Regards.

[andoru]

I can't see anything wrong in the refresh rates - they look completely normal (for LCD).

That's because you've read the refresh rates from my corrected xorg.conf
The ones that are in the xorg.conf that "works" (the one that was generated by the nVidia driver) are:

Code: Select all

    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0

While the correct ones (according to the monitor's manual) are:

Code: Select all

    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 75.0

Your monitor has only VGA connector (according to online specs), so it uses VGA-compatible signals, and the VGA-0 connector on the gfx card. It is also possible, that noveau will report more corect EDID data regarding the resolution, because nvidia has long tradition in making bugs in their randr implementation...
Read this to find out how to resolve the problem.

That's precisely what I was trying to do, to get the correct EDID data out of the monitor, but I can't get it because it connects through VBE instead of I2C, and the author of the utility (read-edid) told me that VBE is for most cases unreliable, and I'd have to make it connect through I2C to get the correct data. That's the question I had initially in this thread.

Regarding Your xcorg.conf - it seems to be correct, but it's sufficient (and sometimes it's better) to provide only one, native resolution for the Monitor/Screen.

You mean to have only one modeline, or only one mode under the "Display" subsection? And what about the other resolutions?

I've mentioned vbeinfo , because it can help in case if no drivers are available for the gfx card and vesa is used as fallback. It won't help You in this case. Of course, just out of curiosity You may check the resolutions reported by vbeinfo: press ESC on Grub2 boot menu/splash, then press 'c' and type vbeinfo.

I've went there, and it seems to have detected the preferred resolution correctly (1366x768), but in the list of available modes it isn't there, all there is are 4:3 resolutions.
Is there any way to fix this as well? So that GRUB2 could also display the list in the native resolution.

EDIT: I tried to edit my xorg.conf to this and it still refuses to start the X session: http://pastebin.com/XQk9qpUr

[tomazzi]

That's precisely what I was trying to do, to get the correct EDID data out of the monitor, but I can't get it because it connects through VBE instead of I2C, and the author of the utility (read-edid) told me that VBE is for most cases unreliable, and I'd have to make it connect through I2C to get the correct data. That's the question I had initially in this thread.

Have You read the "Update" section on the page from my link?
You Don't Have To use 'read-edid'. You can use nvidia-settings->'Acquire EDID', edit the file, calculate the correct checksum, then use CustomEDID option in the xorg.conf
Just in case, here's the link to checksum tool:
http://analogbit.com/software/edid_disable_exts
(it can remove extensions, but this is not needed in Your case)

EDIT: I tried to edit my xorg.conf to this and it still refuses to start the X session

In any case, if You have a problem with X You should first check the /var/log/Xorg.0.log

Regards.

[andoru]

Have You read the "Update" section on the page from my link?
You Don't Have To use 'read-edid'. You can use nvidia-settings->'Acquire EDID', edit the file, calculate the correct checksum, then use CustomEDID option in the xorg.conf
Just in case, here's the link to checksum tool:
http://analogbit.com/software/edid_disable_exts
(it can remove extensions, but this is not needed in Your case)

My bad, I didn't notice that part. I've tried his utility (I have no way of going back to Windows right now), but it seems to have a problem, so either I did something wrong when compiling it, or it works only for AMD64 CPUs. I contacted him and I'll see what I can do

In any case, if You have a problem with X You should first check the /var/log/Xorg.0.log

I checked it, and it seems I wrote the modelines incorrectly, it should have been like this:

Code: Select all

Modeline "1366x768_59.8"   85.50  1366 1436 1579 1792  768 771 774 798 +hsync +vsync

Instead of this:

Code: Select all

Modeline "1366x768"x59.8   85.50  1366 1436 1579 1792  768 771 774 798 +hsync +vsync

Unfortunately this hasn't fixed anything, as it still displays in 1368x768.

[tomazzi]

...but it seems to have a problem, so either I did something wrong when compiling it, or it works only for AMD64 CPUs. I contacted him and I'll see what I can do

Noone will tell You what's the problem basing on such mysterious "report". Any details?

Unfortunately this hasn't fixed anything, as it still displays in 1368x768.

Normally EDID informations about supported resolutions/refresh rates are overriding Modeline - that's why You only need to set the "preferred" one - the rest is already collected by the driver during initialization. Moreover, If Your "preferred" mode does not match any of the resolutions reported in EDID, then the "nearest" mode is used. Theoretically, Option UseEDID=false should disable this behaviour, but I've never seen it working on nvidia (I have tried it for the first time on mobile GF MX200). CustomEDID option works.

Resolutions reported by EDID have "higher priority" over user settings, because it is possible to damage the monitor if f.e. bad sync polarization is set (this was especially true for CRT monitors).

Regards.

[andoru]

...but it seems to have a problem, so either I did something wrong when compiling it, or it works only for AMD64 CPUs. I contacted him and I'll see what I can do

Noone will tell You what's the problem basing on such mysterious "report". Any details?

I didn't give details because I don't know what details to give you (sorry, I'm a Debian/Linux beginner)

So I'll walk through what I did:

Code: Select all

$ tar -xvzf edid_disable_exts_v1.2.tgz  && cd edid_disable_exts/
$ sudo make
cc edid_disable_exts.c libedid.c -g -Wall -pedantic -o edid_disable_exts
$ sudo sh edid_disable_exts /etc/X11/edid.bin /etc/X11/edid.fixed.bin
edid_disable_exts: 1: edid_disable_exts: Syntax error: "(" unexpected

But now as I type I realised I shouldn't have used sh in the first place, so I did this instead:

Code: Select all

$ ./edid_disable_exts /etc/X11/edid.bin /etc/X11/edid.fixed.bin
ERROR: Input EDID does not appear to be valid. (First block has an invalid header.)

That's the edid file I exported through nvidia-settings.

Normally EDID informations about supported resolutions/refresh rates are overriding Modeline - that's why You only need to set the "preferred" one - the rest is already collected by the driver during initialization. Moreover, If Your "preferred" mode does not match any of the resolutions reported in EDID, then the "nearest" mode is used. Theoretically, Option UseEDID=false should disable this behaviour, but I've never seen it working on nvidia (I have tried it for the first time on mobile GF MX200). CustomEDID option works.

Resolutions reported by EDID have "higher priority" over user settings, because it is possible to damage the monitor if f.e. bad sync polarization is set (this was especially true for CRT monitors).

Regards.

Thanks for clearing that one out, makes more sense now. I've tried that option in xorg.conf (since I'm not using a CRT monitor so I should be fine I think, also I've set the correct sync rates) and it doesn't seem to work either. This is how the 'Monitor' section looks like under my xorg.conf:

Code: Select all

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Philips"
    ModelName      "193V5L"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 75.0
    Modeline "1366x768_59.8"   85.50  1366 1436 1579 1792  768 771 774 798 +hsync +vsync
    Option         "UseEDID=false"
    Option         "DPMS"
    Option         "PreferredMode" "1366x768"
EndSection

[tomazzi]

Hi,
I've checked the source code for this little proggy (edid_disable_exts.c, libedid.c) and it seems to be ok (although far from perfection) - could You please attach (somewhere) Your original EDID file (a binary format is acceptable) - I suppose that I know where's the problem (bad file encoding), so I think I can make a fix for it. My EDID is working, so I can't use it for testing...

...and maybe it's time to provide a final solution for this, especially that winblows already has one...

Regards.

[andoru]

Hehe, "winblows" is like a spoiled brat.

Here's the edid file in question:
http://s000.tinyupload.com/index.php?fi ... 4604531578

[tomazzi]

Ok, the problem is that the EDID file is incomplete - "Detailed Timing Descriptor" extension is missing (file is too short).
If this is what nvidia-settings can output, then nv apparently has yet another bug in the drv version which You have installed.
The driver itself must have had read the correct data, because the resolution 1368x768 is not part of the standard structure - it must be defined in the extension, so most likely only the AcquireEDID function does not work properly.

Anyway, I've decided to write EDID editor/parser (GUI), so it will be possible to generate an EDID files for particular monitors. The EDID standard is a mess (like most of that corporate, half-baked, partially-implemented, mostly-confidential crap), but I think I can fully implement EDID v3 (which is using EDID v1.4 structure, just to be more funny) in 2 weeks or so... (I have other projects to work on).

Regards.

[andoru]

Alright, I wish you good luck with that, but in the meantime, what is it that I can do?

[tomazzi]

Alright, I wish you good luck with that, but in the meantime, what is it that I can do?

Well if it was me, I would try to uninstall the nvidia drv, force the vesafb driver to load and then try to extract the EDID data -> this would be similar to what vbeinfo is doing. But, I've never been forced to do this, since I've switched to ATI some time ago (because it's actually better supported on Linux than NV, and the "traditional" performance problems are not valid anymore <with some exceptions>), so, I don't know if it'll work today (with the current vesions of vesafb, kernel and Your gfx card) - so it's entirely up to You.
In case if it'll work, please provide the EDID binary data - that would be helpfull.

Regards.

PS. It's not about luck - I will do this (I already have a GUI layout and most of the v1.4 structure ready), and the only qestionable thing is whether I'll be able to finish it in 2 weeks or not

[andoru]

Hmm, that's rather cumbersome, and I have no idea with what to get the edid data that way. I'll try to see if I can get my friend to bring his laptop with Windows installed on it and use that windows program to extract the edid data, hopefully it will work that way. I'll surely send the edid data once I get my hands on it

PS. It's not about luck - I will do this (I already have a GUI layout and most of the v1.4 structure ready), and the only qestionable thing is whether I'll be able to finish it in 2 weeks or not

Ah I see, haha.
Perhaps then it might be better if I would change this thread to the name of the project you intend to do, so people could find the stuff they need.

The EDID standard is a mess (like most of that corporate, half-baked, partially-implemented, mostly-confidential crap)

Hopefully people will start to realise that there's urgent need for FOSS and OSHW so we could completely shift the paradigm that Microsoft & friends have established

[tomazzi]

Hmm, that's rather cumbersome, and I have no idea with what to get the edid data that way.

Well, the nv drv is apparently blocking an access to VESA BIOS extension, so naturally, without the nv driver there's a chance to get original edid data. But, that's only assumption, as I've mentioned eariler...

Perhaps then it might be better if I would change this thread to the name of the project you intend to do, so people could find the stuff they need.

Yes, that's rather good idea, but I don't want to make any implicit statements about it, before it's ready to publish... (and tested). Personally, I hate beta-software, when it's announced as 'ready to use' - this is the worst thing which may happen for a software project.

Regards.

[andoru]

Yes, that's rather good idea, but I don't want to make any implicit statements about it, before it's ready to publish... (and tested). Personally, I hate beta-software, when it's announced as 'ready to use' - this is the worst thing which may happen for a software project.

Then I could rename the thread and perhaps somebody could sticky it after it's "done"

[andoru]

Alright, I went on Windows as I mentioned earlier, used Phoenix edid editor (and "extractor"), and was able to extract two files, .raw and .dat. Then Idded the "CustomEDID" line to xorg.conf to both at a time, and the log indicates that it is loading it properly, but nothing has changed, so I guess I didn't change much.
So then I went to try edid_disable_exts, to the .raw file it reported that it already had it's extensions removed, and to the .dat file it retorted:

Code: Select all

ERROR: Input file "/etc/X11/PHL193V5L.dat" has a bad filesize (not a multiple of 128)

Anyway, not sure what use it might be to you, but I uploaded the two files: http://s000.tinyupload.com/index.php?fi ... 4476679903

Do you think the windows driver on my friend's laptop could have hindered the transmission of the edid data? If so then I guess I should try the vesafb method you mentioned earlier.

[tomazzi]

I don't know - You may try of course.
I think the problem my be more deeply rooted - f.e. the internal pixelclock counters of Your gfx card are not able to work natively with such uncommon screen resolution - f.e. they may require resolutions divisible by 8. But, DTD (Detailed Timing Descriptor) inside EDID can bypass such limitations by defining "border pixels" - basically, You can have Xres set to 1368, but with 2 border pixels, so the effective X-resolution would be 1366. This however may require to adjust also the Hsync timings, cause otherwise the picure may be just "shifted" in X-axis, what is definitely not what You want.

Regards.

PS. I've decided to name the editor as "wxEDID", to honor the wxWidgets developers (this is quite common - a "tradition" of some kind). EDIDv1.0+ and CEA-EDID are almost ready, the most painfull part involving connectivity between GUI and EDID structures is ready - overall progress: 40%
Unfortunately, I still have problems with finding good/full descrption of v1.4 EDID and CEA "F" specification, but they are not "revolutionary" so the available specifications should be 99% correct.

edit: oh, and thanks for the another EDID snapshot

[andoru]

I don't know - You may try of course.

How would I dump the EDID data in that mode by the way?

I think the problem my be more deeply rooted - f.e. the internal pixelclock counters of Your gfx card are not able to work natively with such uncommon screen resolution - f.e. they may require resolutions divisible by 8. But, DTD (Detailed Timing Descriptor) inside EDID can bypass such limitations by defining "border pixels" - basically, You can have Xres set to 1368, but with 2 border pixels, so the effective X-resolution would be 1366. This however may require to adjust also the Hsync timings, cause otherwise the picure may be just "shifted" in X-axis, what is definitely not what You want.

And how would I be able to do that exactly?

PS. I've decided to name the editor as "wxEDID", to honor the wxWidgets developers (this is quite common - a "tradition" of some kind). EDIDv1.0+ and CEA-EDID are almost ready, the most painfull part envolving connectivity between GUI and EDID structures is ready - overall progress: 40%
Unfortunately, I still have problems with finding good/full descrption of v1.4 EDID and CEA "F" specification, but they are not "revolutionary" so the available specifications should be 99% correct.

That sounds great
I'll edit the thread once you're done.

edit: oh, and thanks for the another EDID snapshot

You're welcome