This is better, since 59.95 is not correct for the fractional refreshrate (59.94006). As you have noted, the porches are the same for all the modes in your latest EDID. That’s telling me all I have to do is change the pixel frequency and all the other parameters will adjust accordingly. The timings you posted above confirm this (subject to rounding errors for DTD3). Vero takes no notice of the horizontal and vertical frequencies. It takes the pixel frequency and porch values to work out the timings. So for ‘23.98’ it will divide 62.4 by 1.001 (62.3376), divide that by h_total*v_total (2080x1250) so that the framerate is 23.976024Hz. This is abbreviated to 23.98 in the GUI. That to me is no different from your DTD3 above.
Yes. You have understood correctly, as I’ve explained. Except there’s no ‘related CEA VIC’. That is why I say those DTDs for fractional rates are not necessary.
In addition, if you have a 256-byte EDID there is only room for 5 DTDs so if you want 60, 50, 30, 25 and 24Hz that’s it - no fractional rates or 48Hz. Here is an EDID that I’ve used to test all those rates which I’ve now coded into our kernel:
I should point out I’ve made that from the EDID you posted above. It seems to be missing a lot of video modes that were in the original Barco EDID.
It should be built and in our ‘staging’ repository in a few days. I’ll give you instructions when it’s available. You should then have YUV422 and RGB 8-bits at all refreshrates. If you confirm that works we can then look at the timings for 10/12-bit RGB and 444.
At the moment there is not. I’ll see to that next.
Ok, now I understand better. I appreciate your support.
Just allow me to disagree here:
CEA-861 VIC mode 32 is 1920x1080@24Hz, and 23.976 is derived from this mode, as you suggested. So they are related.
Those DTDs including 23.976 are necessary for my custom EDID to work on my projector. I can’t take them out. DTD 3 may not be necessary for your calculations for the Vero, but my DTD 4 for 24 Hz is indeed necessary for you since you are taking the pixel clock and porch values that I chose.
I can actually place 7 DTDs on a 256-byte EDID, 4 in Block 0 and 3 in Block 1. Now I have 2 DTDs in Block 0 because I used 2 slots for Range Limits and Display Name. I can take them out since they are actually not necessary for HDMI, but I left them for completeness because I don’t need more rates for now.
I know. I chose it accordingly for simplicity because I won’t use them.
Well that would be … odd. I’ve not heard of an EDID informing it’s device how to work. The problem is, if you had only the fractional rate DTD, Vero would take that pixel frequency as the required one for that mode and, as I said, divide it again by 1.001. Your PJ should still sync OK but your videos will be 0.1% slow. No idea what that would do for a/v sync. And you will need 8 DTDs.
When we publish the kernel, please see if the EDID I’ve posted works. My Dell U2410 syncs at all those pixel frequencies with/without the 1.001 factor using that EDID.
If you do really have to include those fractional refreshrates then please make sure they come before the corresponding non-fractional rate and in the same block. That way the non-fractional rate will be the second one parsed and it will overwrite the fractional rate values (I think - I haven’t tried it).
Not a good idea. We use those range values to check that a given mode (especially when deep colour) is within the display’s capability.
AFAIK, the EDID is a descriptor of the modes a display can present to a device, it basically informs the device of its capabilities in order to work with it. If I remove the 23.976 DTD, Windows won’t offer that refresh rate. It’s the whole purpose of the EDID, and that’s the reason I made it. A EDID that works with all devices.
Now, if you say that the Barco will output 23.976 from the Vero by replacing my EDID with yours without the 23.976 DTD, now that will be odd, because we are essentially forcing a custom VESA mode the EDID doesn’t provide.
If you say so, I can try it, but it’s odd to me. Otherwise what I can do is lower the 23.976 DTD from the Block 1 below the 25 and 24 ones.
Is the reason behind your recommendation to removing my 23.976 DTD based on the fact that you force your own ‘23.98’ mode with timings that are different from mine and that they may clash? You say you get 23.976024 Hz. My DTD 3 gets or says 23.976923.
P.S: Could you please add an additional mode for 50 Hz such as this? Same porches. I may need it for 25i content:
Ok, I’m learning something. In the CEA world, which 99.99% of our users inhabit there are no separate VICs for each mode so we have to assume that if a display supports 30Hz it also supports 29.97Hz. We do the same for VESA modes (I was wrong when I suggested otherwise above).
If I plug my Dell monitor into Windows (11) I’m offered only 60Hz, even if choose a CEA mode (1080p60). If I plug a TV into Windows, I’m offered fractional rates for both CEA and VESA modes (including a VESA mode that’s defined by a DTD - 1366x768). I don’t know what the difference is. Your PJ does has a CEA extension block with HDR capabilities and a range of CEA modes just like my TV, so why doesn’t Windows offer fractional rates unless you make explicit DTDs for them?
Update: It seems Windows does this:
CEA mode - fractional rate can be set
VESA mode - fractional rates are listed but if I choose one the resolution switches to a CEA mode
So I now understand your issue with Windows, but it won’t happen like that on Vero.
I think it is simpler than that: WUXGA is a VESA resolution. To set a refresh rate for this native resolution available on Windows, we need a DTD (or a STI) on the EDID. My projector stock EDID sets DTD1 with timings for native 1920x1200 at 59.950171 Hz (which is a VESA Reduced Blanking Monitor Timing Standard). This is the refresh rate a device should output for this resolution by default. From then on, I can modify this DTD at the EDID and add more resolutions and refresh rates including fractional, which the device should follow if supported by the display.
This means your TV must have a DTD with a fractional rate for 1366x768. Windows can’t offer it by default.
Because Windows doesn’t know of fractional rates for a VESA mode. It needs a DTD. And a device like Vero is supposed to aswell. If you can whitelist its timings on its firmware it’s ok as long as it coincides with the DTD on my EDID or it is accepted by the projector.
Now, as the 23.976024 Hz vertical frequency mode you calculate by deriving from the porches and pixel clock from my 24 Hz DTD (you divide it by 1001 as if it was from a CEA mode) is different from my 23.976 DTD (23.976923 Hz), we assume it is going to work, but they are slightly different frequencies: there might be a drift. Or I guess your timing just overrides mine.
With my custom EDID difining a 60.000 Hz exact DTD now, the Vero offers 59.94 and 60 Hz resolutions in the GUI. May I guess that the Vero constructs the 59.94 rate timings from my main 60.000 Hz DTD which is the 60 Hz rate offered? Or does it use the Vero’s internal timings for both? This can get hard to understand..
That’s to say, if the Barco accepts your 23.976024 Hz hardcoded frequency and ignores my DTD, it is all the better to me, because it actually approximates better to the ideal of 23.976. So, in the end, it’s all for the best to me, I could delete my DTD for 23.976 (and maybe also all others except the main 60 Hz one?) and expect the projector to obey your vertical frequency timings. So let your timings rule!
P.S: Coincidentally on May 26, we are projecting a 1.64:1 23.976 movie, ‘La mujer murciélago (1968)’. If everything goes well, I’ll be using our coveted WUXGA rate.
I have entered staging osmc-devel list and updated, now I am on 4.9.269-94-osmc kernel and 2025-05-1.
osmc@osmc:~$ uname -r
4.9.269-94-osmc
osmc@osmc:~$ ls /etc/apt/sources.list.d
osmc-devel.list
osmc@osmc:~$ cat /etc/apt/sources.list.d/osmc-devel.list
deb http://apt.osmc.tv bullseye-devel main
Am I on the good version? Thanks in advance for your support and patience with me
With my custom EDID, first version I see 60 and 59.94 Hz available for 1920x1200 for now, as with stock EDID.
Thanks Graham. By curiosity, actual 60 and 59.94 Hz modes for WUXGA are based on which timings, mine from my main DTD1 @ 60.000 Hz, or the one from stock Vero? I’d like, if possible for all modes to share the same timings (porches, sync and polarity).
I stand by for next tuesday, we’re projecting a 23.976 1.66:1 movie, would wish to use native 1920x1200.
We are using the porches, etc from the DTD. We only use timings from the database in the kernel for CEA, established and standard modes. And as I explained, 59.94 is derived from 60Hz by scaling the pixel frequency.
Okay. So I deduce the Vero only reads the first DTD from the EDID for a VESA resolution, and derives the 1000/1001 refresh rate from it (59.94). The rest of the rates (24, 25, 30, 48 and 50) have been added by you as a patch for the next staging kernel, along with the 1000/1001 variants for 23.976 and 29.970.
By curiosity, can this patch be applied to the stable kernel by using the OSMC GUI option to import a patch, so I can do it rightaway without moving to staging and waiting for a new kernel?
@wyup the patches are now in staging. You may have to wait an hour or so for the mirrors to update.
I’ve added those refreshrates but only for 8 bits so you don’t want to use RGB output for 10-bit sources. It should give you YUV422 automatically if you don’t force it to RGB.
I’ve also arranged for full-range input to be recognised as such. Vero won’t handle DCPs directly of course.
Thanks. I updated but at the 1920x1200 modes I get inconsistency in the GUI and a blank screen on the Barco, probably because of the 8-bit limit you set. This is the console details for this mode for the few seconds in blank screen before switching back to 1920x1080:
osmc@osmc:~$ cat /sys/class/amhdmitx/amhdmitx0/config cur_VIC: 794 cur_video_param->VIC=794 cur_video_param->colordepth: 8bit para->colorspace: 444 AVIF VIC: 0 VIC: 794 1920x1200p24hz Colour depth: 14-bit Colourspace: YUV422 Colour range: limited EOTF: SDR YCC colour range: limited Colorimetry: no data PLL clock: 0xdb0604d0, Vid clock div 0x000a739c Aspect ratio: no data/full frame DV type Not DV audio config: on audio on/off: on audio source: I2S audio type: L-PCM audio channel num: 2 channels audio sample rate: 44.1kHz audio sample size: MAX 3D config: off
It strangely says Colour depth: 14-bit but it also output this on another blank screen:
osmc@osmc:~$ cat /sys/class/amhdmitx/amhdmitx0/config
cur_VIC: 794
cur_video_param->VIC=794
cur_video_param->colordepth: 10bit
para->colorspace: 444
AVIF VIC: 0
VIC: 794 1920x1200p24hz
Colour depth: 12-bit
Colourspace: YUV422
Colour range: limited
EOTF: SDR
YCC colour range: limited
Colorimetry: no data
PLL clock: 0xdb0604cf, Vid clock div 0x000a739c
Aspect ratio: no data/full frame
DV type Not DV
audio config: on
audio on/off: on
audio source: I2S
audio type: L-PCM
audio channel num: 2 channels
audio sample rate: 44.1kHz
audio sample size: MAX
3D config: off
I have tried forcing 8-bit with echo “8bit” | sudo tee /sys/class/amhdmitx/amhdmitx0/att but it doesn’t work. I haven’t forced RGB on the GUI as you suggested.
We need 10/12-bit enabled for all 1920x1200 rates just like you did on the latest stable update for 60 Hz so the automatic handshake doesn’t crash the video pipeline.
1920x1200@60Hz for example works:
osmc@osmc:~$ cat /sys/class/amhdmitx/amhdmitx0/config cur_VIC: 789 cur_video_param->VIC=789 cur_video_param->colordepth: 10bit para->colorspace: 422 AVIF VIC: 0 VIC: 789 1920x1200p60hz Colour depth: 12-bit Colourspace: YUV422 Colour range: limited EOTF: SDR YCC colour range: limited Colorimetry: no data PLL clock: 0xdb010482, Vid clock div 0x000a739c Aspect ratio: no data/full frame DV type Not DV audio config: on audio on/off: on audio source: I2S audio type: L-PCM audio channel num: 2 channels audio sample rate: 44.1kHz audio sample size: MAX 3D config: off
I tried changing to 1920x1200 on a live 1920x1080@23.976 8-bit playing video and I got the screen locked into a blank screen and couldn’t get away even after rebooting the Vero. I had to manually edit /home/osmc/.kodi/userdata/guisettings.xmland set this default mode manually:0192001080024.00000pstso I regained control of OSMC.
Thanks again for your work, hope we can finally make it.
I don’t know why you are getting that. For me it says 422. Everything else is the same, including the ‘14-bit’ print if I force 8 bits, but I get a picture in all cases. I suggest trying the 24Hz mode immediately after a reboot.
Don’t write anything to the attr parameter - clear it with: echo now | sudo tee /sys/class/amhdmitx/amhdmitx0/attr
Note: no need for “” round the 8bit or the now and the parameter is attr, not att.
Update: I have managed to get a blank screen and also para->colorspace: 444 when attempting to change the resolution while playing a movie. But if I set the resolution and refreshrate in the GUI (you didn’t say whether that works for you) then play a movie with ‘Adjust display refreshrate’ Off everything seems fine.
Update 2: If I reboot after setting 1920x1200p24hz I get no picture (even if I force 422 in settings). I can recover the situation with echo 1920x1200p60hz | sudo tee /sys/class/display/mode (no need to hack guisettings). 1920x1200p60hz is OK on a reboot. So for your screening, you can try this:
reboot in 1920x1080p or 1920x1200p60hz
switch to 1920x1200p23.98hz
turn off Adjust display refreshrate
play your movie
I don’t know why it won’t boot to 1920x1200p24hz or change to that on the fly and I won’t have time to fix it today.
This is the EDID I’m using. I removed the 30 Hz DTD on block0 and put a 50 Hz with the same timings. First DTD is the same 60 Hz. I reordered the block1 DTDs for 25, 24, and 23.976 with the same timings:
I get inconsistent behaviour: right off the bat 25, 24 and 23.976 worked for the GUI. But then after rebooting and switching to1920x1080@24/25/23.976 the Barco won’t display those rates for 1920x1200 and go blank, returning after some seconds to previous 1920x1080. And then when playing a 23.976 1800x1080p 8-bit movie that switches to 1920x1080/23.976 (whitelisted), changing to 1920x1200 goes to a blank and doesn’t recover for itself. I tried with a blank whitelist and force 1920x1200@23.976 playback but it didn’t work, it wouldn’t switch.
i’d use echo now | sudo tee /sys/class/amhdmitx/amhdmitx0/attr and echo 1920x1200p60hz | sudo tee /sys/class/display/mode as you suggest.
But right now I find 25, 24, and 23.976 inconsistent. I could project at 1920x1200/59.94 and do a 3:2 pulldown just for the 23.976 movie. But it’s complicated because we project other material before which is 1080p/24/25 and 2160p/24. I could just whitelist 1920x1200 @ 23.976/24/25 and discard 1920x1080 modes (which is my intention) but I am not confident with these 1200p/23.976/24/25 yet and can’t afford a blank in front of the audience, since I get inconsistent or unexpected behaviour after playback.
It seems this problem is related to the 8-bit limitation for 25, 24, 23.976 at WUXGA you referred before, and this clashes with the other modes at deep colour when doing playback, but also for the GUI. I could force load echo 8bit | sudo tee /sys/class/amhdmitx/amhdmitx0/attr in /etc/rc.local, but it seems too forceful or uncertain, since i don’t know whether switching modes would override this.
I think this because your EDID advertises deep colour but I haven’t coded up for 10 bits or 12 bits YUV444.
If you have the means to do it, can you change your EDID so it looks like the Barco doesn’t do deep colour, then Vero should go into 8-bit mode on boot and you should still be able to play in YUV422.
That’s all I can think of right now. Except I’ll say it again: you don’t need a 23.98Hz DTD. My Dell switches to 23.98Hz without that - you can try the EDID I posted today.
We can’t go backwards with the EDID. Your EDID allows 10 and 12 bits aswell for HDMI1.4/2.0, as does the Barco stock. Barco stock EDID only had limited range for Block 0 descriptor, but the whole purpose with Barco was to select the full usable range for everything. I understand I don’t need the 23.98 DTD on the EDID, but it doesn’t hurt either, does it? It’s the last on the block1 list. I have problems with 24 and 25 aswell for 1920x1200.
I’d rather wait until you enable YUV444 and RGB for 10 and 12 bits for WUXGA, since this was the whole purpose of this thread, or at least 10/12 bit YUV422 so it all works fine with no hiccups.
So let your timings rule!
