EDID Override - Injecting a Dolby VSVDB Block

Unsupported/EOL HW/SW Community Projects
1

@DMDreview @philgaultier

FYI @doppingkoala

Looks like there is already a way to change the EDID in the Linux AMLogic implementation - based on some quick searching around.

If I am correct the EDID is written to a file and can be overridden with what we want, so in theory if we have a basic LLDV Dolby VSVDB block I think we could add that to the file (probably need to also update a count somewhere in the EDID for the number of extensions etc. to make it consistent) and there is a reasonable chance this will work - not guarantees at this point, may turn out to be a damp squib, but willing to give it a shot.

Before I look further and try to give some instructions, just want to confirm you are up for some testing, it a serious pain to de-install my setup and move to a HDR monitor each time just to do some testing so need some help ideally with someone who can control and view the EDID with say a HDFury, and some basic knowledge/understanding of what we are talking about here.

Will try to look into this more in the next few days if someone wants to try.

Some tech bread crumbs to search in code, if anyone is following along with some dev knowledge - all help welcome!

linux-amlogic/drivers/gpu/drm/drm_debugfs.c
edid_override
file_operations drm_edid_fops
	edid_open
	edid_write
6 Likes
2

You probably already thought of this, but can you not just change the mode of your HDMI ports to one that doesn’t support DV?

3

Thanks, did not think of that - mind you probably because don’t recall seeing an option to enable DV per HDMI (on E8 LG) though will now take another look later on :slight_smile:

4

I can do some testing on a SONY screen on which I guess I can disable DV. On my Formovie Theater projector I think I can’t disable DV to make it HDR-only however.

I have a HDfury Vertex2 and ugoos am6b+ so I’ll be glad to help and participate in this matter, but not before monday 20th as I have big dutties before :slight_smile: . Thanks a lot for what you do. It’s cool to “jailbreak” the DV ecosystem a little bit more …

(and I’m probably in a different timezone as you, I’m in europe)
(… and I also have a PC monitor which is HDR-only compatible so I can indeed reproduce the real use case)

5

Thanks, in no rush my side - can do as time permits.

Goals are:

  1. See if can edit the EDID and add a Dolby VSI. Check if that then does correct colours for p7 FEL (VS10) DV → HDR10

  2. If good, then try for holly-grail - see if can send to TV as LLDV (but flipped with a flag to make it trigger HDR instead)

  3. Look for some sensible way to build a Dolby VSI that is appropriate for the attached display. (Presuming existing devices have some pre-built VSI blocks for well known displays?)

1 Like
6

To me it seems that 1. and 2. are little different ways to achieve the same thing right ?

  • in 1. the HDR10 flag is sent anyway but in other thread we found that tone-mapping including FEL is not done correctly (if I remember correctly we found that it basically only takes the hdr10 layer as is, right ?, so for the moment its only added value was to display correct color with DVp5 input, right ?) and so maybe the tone-mapping is done correctly only if a DV EDID is detected… ? (the purpose of initial use case would be weird : doing a DV->HDR10 conversion, only if your monitor is DV compatible :rofl: )

  • in 2. That is the clone of the so-called “LLDV trick”, but why would it need the method 1. to be working ? If we trick the dovi module to produce LLDV output, VS10 should not be necessary anyway right ? maybe I’m mistaken here …

  • for 3. I have a library of well known displays EDIDs in HDfury indeed and I guess I can extract them… will check that as soon as I can.

in 1. and 2. there can also be an added value for screens that are DV compatible but with a bad DV implementation (or old one) … and that’s the case of the formovie theater projector actually.

7

Yeah not much difference but easier to do for VS10 first.

For 1 - there are a couple of problems to try and address:

  • p7 FEL colours are wrong, though for MEL they are fine.
  • p7 FEL and MEL RPU looks like not being used.
  • p5 colours look correct, but need to confirm if the RPU is being used.

Yeah correct: DV → HRD10 - but faking that the monitor is DV compatible because it is actually not - just for it to work a bit better. :slight_smile:

(Not holding out much hope the RPU will correct because my LG with the VSI is not responding to the RPU even though the colours are correct for p7 FEL - the theory being because it has a VSVDB).

Note: Mapping down to SDR10 or SD8 then for some reason the RPU starts to be used - so I think this is a bug somewhere else - probably not accessible to fix for us though.

If could do 2 then agreed not much need for 1, but 2 involves more changes for the HDR flagging, so 1 is more about proving can edit the EDID ok and get some minor value before tackling that.

If everything else was equal colours/rpu processing etc. I also think LLDV still has the slight upper hand as I guess it is 12bit “HDR” vs 10bit HDR from VS10.

1 Like
8

ok, extract and load looks promising:

cd /sys/class/amhdmitx/amhdmitx0/
echo save txt ~/edid.txt > edid

get a file in home dir:

/storage/edid.txt

and message in log:

hdmitx: [dump_edid_data] write 1536 bytes to file /storage/edid.txt

can then load the same file back with:

echo load ~/edid.txt > edid

and messages in log:

hdmitx: [load_edid_data] 1024 bytes loaded from file /storage/edid.txt
hdmitx: edid: EDID Parser:
hdmitx: Edid_ParsingVendSpec:ieeeoui=0xd046,len=11
hdmitx: v1 VSVDB: len=11, sup_2160p60hz=1, low_latency=1
hdmitx: Edid_ParsingVendSpec:ieeeoui=0xd046,len=11
hdmitx: v1 VSVDB: len=11, sup_2160p60hz=1, low_latency=1
hdmitx: edid: get dtd0 vic: 97
hdmitx: edid: get dtd1 vic: 16
hdmitx: hdmitx: get PMT vic: 97
hdmitx: edid: find IEEEOUT
hdmitx: [load_edid_data] new edid loaded!

file is a bunch of hex values:

0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x4d, 0xd9, 0xd1, 0x05, 0x01, 0x01, 0x01, 0x01,
0x31, 0x1e, 0x01, 0x03, 0x80, 0xa0, 0x5a, 0x78, 0x0a, 0xee, 0x91, 0xa3, 0x54, 0x4c, 0x99, 0x26,
0x0f, 0x50, 0x54, 0x20, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x08, 0xe8, 0x00, 0x30, 0xf2, 0x70, 0x5a, 0x80, 0xb0, 0x58,
0x8a, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e, 0x02, 0x3a, 0x80, 0x18, 0x71, 0x38, 0x2d, 0x40,
0x58, 0x2c, 0x45, 0x00, 0x40, 0x84, 0x63, 0x00, 0x00, 0x1e, 0x00, 0x00, 0x00, 0xfc, 0x00, 0x4c,
0x47, 0x20, 0x54, 0x56, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xfd,
0x00, 0x3a, 0x79, 0x1e, 0x88, 0x3c, 0x00, 0x0a, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x01, 0x88,
0x02, 0x03, 0x6c, 0xf0, 0x59, 0x61, 0x60, 0x5d, 0x5e, 0x5f, 0x62, 0x10, 0x1f, 0x05, 0x04, 0x13,
0x14, 0x20, 0x22, 0x21, 0x83, 0x12, 0x02, 0x01, 0x65, 0x66, 0x63, 0x64, 0x3f, 0x40, 0x35, 0x0f,
0x7f, 0x07, 0x15, 0x07, 0x50, 0x3d, 0x1f, 0xc0, 0x57, 0x04, 0x03, 0x67, 0x54, 0x03, 0x5f, 0x7e,
0x03, 0x5f, 0x7e, 0x01, 0x83, 0x5f, 0x00, 0x00, 0x6e, 0x03, 0x0c, 0x00, 0x21, 0x00, 0xb8, 0x3c,
0x20, 0x00, 0x80, 0x01, 0x02, 0x03, 0x04, 0x67, 0xd8, 0x5d, 0xc4, 0x01, 0x78, 0x80, 0x03, 0xe2,
0x00, 0xcf, 0xeb, 0x01, 0x46, 0xd0, 0x00, 0x26, 0x18, 0x03, 0x91, 0x82, 0x69, 0x7c, 0xe3, 0x05,
0xc0, 0x00, 0xe5, 0x0f, 0x03, 0x00, 0x18, 0x00, 0xe3, 0x06, 0x0d, 0x01, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x5e,

this matches Dolby VSVDB from elsewhere in the system - not sure if that all the info or maybe some more lines:

0xeb, 0x01, 0x46, 0xd0, 0x00, 0x26, 0x18, 0x03, 0x91, 0x82, 0x69, 0x7c,

looks a promising start anyway.

[ 2918.415181@2]- ******rawedid******
[ 2918.415181@2]- 00ffffffffffff004dd9d10501010101311e010380a05a780aee91a3544c99260f50542000000101010101010101010101010101010108e80030f2705a80b0588a0040846300001e023a801871382d40582c450040846300001e000000fc004c472054560a20202020202020000000fd003a791e883c000a202020202020018802036cf05961605d5e5f62101f0504131420222183120201656663643f40350f7f071507503d1fc05704036754035f7e035f7e01835f00006e030c002100b83c2000800102030467d85dc401788003e200cfeb0146d0002618039182697ce305c000e50f03001800e3060d01000000000000000000000000000000000000005e

[ 2918.415142@2]- ******dv_cap******
[ 2918.415142@2]- DolbyVision RX support list:
[ 2918.415142@2]- VSVDB Version: V1(12-byte)
[ 2918.415142@2]- 2160p60hz: 1
[ 2918.415142@2]- Support mode:
[ 2918.415142@2]- DV_RGB_444_8BIT
[ 2918.415142@2]- LL_YCbCr_422_12BIT
[ 2918.415142@2]- IEEEOUI: 0x00d046
[ 2918.415142@2]- EMP: 0
[ 2918.415142@2]- VSVDB: eb0146d0002618039182697c
1 Like
9

I am almost sure this will not work as you will need to reboot to restart the drivers with the new EDID.
Then it’s gone again…

10

The point is to get the DV info into the dovi.ko.
If it works then great if not then will move on.

1 Like
11

Below is an interesting online tool that can decode the EDID including the Dolby VSVDB.

https://people.freedesktop.org/~imirkin/edid-decode/

Can just past the above hex values in for example, and see this for my LG connected via a Sony HT, it decodes the luminance and RGB xy, looks to me all info is in the 12 bytes, so just need a way to inject that, looks like there is a checksum on “Block 1, CTA-861 Extension Bloc”, which contains the VSVDB so that probably needs to change.

Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 1 (12 bytes)
    Supports 2160p60
    DM Version: 3.x
    Colorimetry: P3-D65
    Low Latency: Standard + Low Latency
    Target Min Luminance: 0.00006200 cd/m^2
    Target Max Luminance: 700 cd/m^2
    Unique Rx, Ry: 0.68359375, 0.32031250
    Unique Gx, Gy: 0.25390625, 0.70312500
    Unique Bx, By: 0.14062500, 0.04687500

LG E8 and Alternative VSVDB for testing later today:

0xeb, 0x01, 0x46, 0xd0, 0x00, 0x26, 0x18, 0x03, 0x91, 0x82, 0x69, 0x7c,
0xeb, 0x01, 0x46, 0xd0, 0x00, 0x2a, 0x38, 0x01, 0x51, 0x59, 0x99, 0xaa,

To see if can just override on my TV as a first step.

12

ok, after much fiddling about getting the right binary format for the edid to load I finally managed to make it work, though a combination of the online tool posted earlier and hex fiend on a mac.

I managed to replace the EDID VSVDB from my TV with one from a newly created edid file, and can at least see the higher luminance being picked up in this log:

DOLBY: v 1: 3840x2160 0->0(T:1-1500),g 1: 1920x1080 1->15000000,vpr

Previously my LG E8 TV was min 1 and max 700 and then changed the EDID VSVDB to:

Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 1 (12 bytes)
    Supports 2160p60
    DM Version: 4.x
    Colorimetry: P3-D65
    Low Latency: Standard + Low Latency
    Target Min Luminance: 0.00000000 cd/m^2
    Target Max Luminance: 1500 cd/m^2
    Unique Rx, Ry: 0.70703125, 0.29296875
    Unique Gx, Gy: 0.17187500, 0.79687500
    Unique Bx, By: 0.13281250, 0.04687500

And get min 1 (code does not allow 0 so bumps up to 1) and max 1500.

So looking good so far, next is to add the VSVDB to a non DV TV EDID and see what that gives!

Thats a bit more involved for me moving around my setup, will give it a go later on.

4 Likes
13

so curiosity got the better of me, and moved my ugoos over to a non-DV but HDR computer monitor.

  • Uploaded the same EDID as I had modified for my LG TV test, though should really create a new one based on the monitors EDID (but good enough for this test)
  • Restart (not reboot) Kodi
  • Kodi picks up we have a “DV” display attached.
  • Change to Player Led (LLDV)
  • Play a p7 FEL - and looking good!
    • BL and EL (FEL) combing correctly and playing
    • Colours correct (no longer green and purple)
    • RPU is being applied
    • HDR though not triggered as not sending an HDR SEI to the monitor.

Edit:

  • VS10 DV → HDR10 - Play a p7 FEL
    • BL and EL (FEL) combining correctly and playing
    • Colours correct (no longer green and purple)
    • HDR10 correctly picked up by display and switched
    • RPU though is still not responding as far as I can tell.
      • This is a real shame, but I believe a bug in the closed source dovi.ko
    • For VS10 DV → SDR10 or SDR8 though the RPU is responding so if that if your use case then this is looking like a great option.

Notes:
You can place the update for an EDID in autostart.sh and Kodi will then not need restarting to pick up.
Doing a hot plug of the HDMI it will reset back to the EDID of the display, so would need a load / reboot etc. to pick up again - annoying but not the end of the world. Possibly someone could write code to load again on a hot plug! maybe.

So I think that proves it! - this can be done - so will call it solved for this thread.

What next:

  • Last element would be to send HDR SEI to the TV to trigger it into HDR BT.2020 etc. - Any takers to investigate that? or know an easy way to do that on the command line? :slight_smile:

  • I think the best approach would be to have some code take the currently connected HDMI EDID and dynamically on the fly add a Dolby VSVDB of choice and load that EDID, not trivial but a nicer solution.

  • It requires knowledge about the display as to what to put in the Dolby VSVDB to be most effective.

  • I guess this is still probably too complex for mainline adoption if someone actually did the above changes.

  • Later will do a post on how to best create an EDID once I get to grips with and investigate the tools below - it was very hand crafted first time around!

Note: I think for some TV could also manually trigger into HDR via service menus etc.

Found these for editing EDID:

8 Likes
14

For anyone interested in this and has a sony tv, there is an option in the picture setting menu to manually set the hdr mode

15

Quick update:

I managed to get the Ugoos sending HDR when in Player Led - LLDV
Edit: Checked on a HDR monitor and LG E8 both good and switch to HDR mode.

So to recap for a non-DV display could do:

  • Load an EDID with a Dolby VSVDB block.
    • Ideally in the future the VSVDB would be dynamically injected into the current EDID, so would work in any setup rather than having to create a custom EDID for the specific setup (e.g. a soundbar / receiver / other device combined with display etc.)
  • Enable Player Led (LLDV)
  • Use new setting: Use HDR output for Player Led.
    • This switches from sending VSIF packets, to HDR packets based which are based the dv hdr info.

All looks to be working correctly (colour, rpu, fel etc.) but needs a deeper analysis on the picture quality.

I can share a build later with the changes for the new parameter alongside a tutorial on the EDID side, want to wait for CE team to finish the implementation they want to do for DV (VS10) - so not too many moving parts and build on top.

Saying that if really keen to try and you think you have a grip on the EDID bit then will share maybe privately to start.

4 Likes
16

Actually maybe worth sharing now; @DMDreview when you get some time if you could compare normal LLDV vs HDR for LLDV it would be appreciated to make sure I am on the right track.

This is built on my VS10 base, with an additional setting:
Use HDR output for Player Led

Note: for this build VS10 for Dolby Vision is back active for all profiles, though goes without saying should leave it off for the testing.

17

@cpm could edid from EDID thread (RTD1619DR players) | Zidoo forum be used ?

18

Yeah looks like it, basically normally 2 128byte blocks so file size in most cases would be 256byte

Can use the load command from the first posts here to try and load, it will not tell you if it failed, but can check the dmesg logging I put some “fail” logging in when it cannot pass the checksums etc and fails to load for some reason.
Note: when it fails to load it just reloads the existing without any indication there was an error, so for a while that threw me thinking everything was fine until added the “fail” logging, and worked out the correct format for the EDID files.

Edit: I tried the first one from that list, it loads ok, but looks like not changing the max nits for me in the logging, so not sure.

I do see they contain V2 DV VSVDB, but would think that should be fine, as I guess quite a few displays been tested with CE are V2.

 Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 2 (12 bytes)
    Supports YUV422 12 bit
    DM Version: 3.x
    Backlt Min Luma: 100 cd/m^2
    Interface: Low-Latency
    Supports 10b 12b 444: Not supported
    Target Min PQ v2: 0 (0.00000000 cd/m^2)
    Target Max PQ v2: 2640 (385 cd/m^2)
    Unique Rx, Ry: 0.70703125, 0.28906250
    Unique Gx, Gy: 0.16796875, 0.79687500
    Unique Bx, By: 0.12890625, 0.04296875

Looking at the code which sets up the min and max luminance, it is only looking at dv version 1, so that explains why I do not see a change from the logging:

 if (vinfo->vout_device->dv_info->ver == 1) {
	if (vinfo->vout_device->dv_info->tmaxLUM) {

As all the VSVDB info I think is passed down to the dovi.ko this may not matter and possibly it handles v2 differently there, but no source code for that so don’t know what it does - will need empirical testing to check if correct.

Unfortunately though this means no easy way to tell the EDID is in effect from the existing logging on these DV V2 EDID.

19

Very good, i will check tomorrow

1 Like
20

Req if you are up for the task @cpm to create a Custom edid based of this pic ? I don’t know what to do with it but found out from avsforum what it should look like on my pj. Im also using a mac so the tools above wont work to make my own edid either i guess :lying_face:

IMG_2281
IMG_22811797Ă—187 14.1 KB