Threaded Mode | Linear Mode

Nodens · 11-12-2023, 02:52 PM

Now sure if this has been asked before but I couldn't find anything on search.

Is it possible to somehow workaround DisplayPort Deep Sleep so that monitors without an OSD toggle don't disconnect on sleep?

Thanks

Espionage724 · 11-12-2023, 04:13 PM

With Intel UHD 630 (31.0.101.2125), Windows 10 (10.0.19044), and Acer S271HL connected via HDMI, if I use CRU to do CVB-RB (v1 or v2) at 74Hz, sometimes after the monitor suspends my entire computer freezes and I need to hard-reboot.

On the same computer/monitor/cord with Linux, video=HDMI-A-1:1920x1080@74 works fine through suspends and wakes and without any issue both Xorg and Wayland.

Can I try or do anything to have 74Hz stable through monitor suspends/wakes on Windows?

***ToastyX*** · 11-13-2023, 02:16 AM

(11-12-2023 04:13 PM)Espionage724 Wrote: With Intel UHD 630 (31.0.101.2125), Windows 10 (10.0.19044), and Acer S271HL connected via HDMI, if I use CRU to do CVB-RB (v1 or v2) at 74Hz, sometimes after the monitor suspends my entire computer freezes and I need to hard-reboot.

On the same computer/monitor/cord with Linux, video=HDMI-A-1:1920x1080@74 works fine through suspends and wakes and without any issue both Xorg and Wayland.

Can I try or do anything to have 74Hz stable through monitor suspends/wakes on Windows?

You need to report that to Intel because there's no reason for that to happen.

***ToastyX*** · 11-13-2023, 02:17 AM

(11-12-2023 02:52 PM)Nodens Wrote: Is it possible to somehow workaround DisplayPort Deep Sleep so that monitors without an OSD toggle don't disconnect on sleep?

DisplayPort monitors aren't supposed to disconnect when they sleep, only when turned off. There isn't anything that can be done on the computer's end if the monitor disconnects unless the GPU supports EDID emulation, which is only offered on Quadro and FirePro GPUs. The only other option is an external EDID emulator, but I don't know any good DisplayPort ones.

***ToastyX*** · 11-13-2023, 02:19 AM

(11-09-2023 06:09 PM)opa99 Wrote: My challenge has been that in CRU the maximum Hertz is always 60 for these high resolutions (at least what I have been able to achieve), and then I later change the Hertz in Nvidia settings.

What do you mean? Where is the maximum you are seeing, and where are you changing the Hz in NVIDIA settings?

(11-09-2023 06:09 PM)opa99 Wrote: I have not put a lot of thought into these clock or blanking values, but instead used the "Automatic HDTV" presets, since I can see that those change with the refresh rate. Would there be a source where I could read and learn what these "do" and how I should change them?
Earlier I did check Monitortests main page for the explanations, but what I can understand from there is, that with modern displays (I understand this also includes TVs), I can reduce blanking, but what I do not understand is why I would like to reduce it? Thank you for bringing up the audio requirements for the blanking, this I had not understood earlier.

The blanking parameters basically just give some break time between lines and frames, which was more important for CRT monitors because they needed time to move the electron guns. HDMI uses the blanking periods to transmit audio because that portion of the signal isn't visible. "Automatic HDTV" takes care of that for TV resolutions listed in the CTA-861 standard, but for non-TV resolutions, it's the same as "Automatic PC" which uses the CVT reduced blanking standard. The blanking can be reduced further to reduce the bandwidth if you're close to a pixel clock limit, which is the total number of pixels per second. Otherwise it doesn't really matter.

(11-09-2023 06:09 PM)opa99 Wrote: Also what is a bit puzzling is the max bandwidth settings in extension blocks, I do not fully understand how I should set them. I have HDMI 2.1 connectors (and cable) on both ends, so I would assume that the generic 600 MHz maximum is not the limit, but for some reason that seems to work for me, even though with the calculators it should not (for 3840x1500 @120hz, with HDR)... The bandwidth limit on my GPU is 48 Gbps and on the TV (receiving) the limit is 40 Gbps, but I have no idea what that would be in TMDS limit, or if that is even relevant for HDMI 2.1.

So any link where I could learn more on the pixel clocks / blanking / extension block details would be appreciated.

You don't need to change any of that. The maximum TMDS character rate for HDMI 2.x should be no more than 600 Mcsc, and that only applies to TMDS signals. FRL signals use the maximum FRL rate, which should already be set to 40 Gbps as reported by the TV. HDMI is a proprietary standard and isn't freely available, so it's hard to find information about HDMI 2.x online. The CTA-861 extension block and data blocks are defined in the CTA-861 standard available here: https://shop.cta.tech/products/a-dtv-pro...-cta-861-i

***ToastyX*** · 11-13-2023, 02:19 AM

(11-09-2023 11:36 AM)RonDamon Wrote: I also have a Samsung TV, more precisely a 43" QN90B model and also it doesn't show those extension blocks. I wanted to edit the max luminance to use an ICC profile. There is no other way to edit the max luminance of HDR?

I'll put the test.txt here as well in the hope that this can help something lol

I can give you the EDID with the extension count changed so it can be imported into CRU. I wanted to add a workaround so CRU can read the extension blocks, but last I checked NVIDIA ignored EDID overrides for displays that have this problem. Let me know if you can make any changes take effect.

.dat

edid.dat (Size: 1.53 KB / Downloads: 195)

***ToastyX*** · 11-13-2023, 02:19 AM

(11-09-2023 08:12 AM)wolik Wrote: Thank you so much!

Same as above, this is the EDID with the extension count changed so it can be imported into CRU, but last I checked NVIDIA ignored all changes for displays that have this problem. Let me know if you can make any changes take effect.

.dat

edid.dat (Size: 1.53 KB / Downloads: 209)

Nodens · 11-13-2023, 08:37 PM

(11-13-2023 02:17 AM)ToastyX Wrote:
(11-12-2023 02:52 PM)Nodens Wrote: Is it possible to somehow workaround DisplayPort Deep Sleep so that monitors without an OSD toggle don't disconnect on sleep?
DisplayPort monitors aren't supposed to disconnect when they sleep, only when turned off. There isn't anything that can be done on the computer's end if the monitor disconnects unless the GPU supports EDID emulation, which is only offered on Quadro and FirePro GPUs. The only other option is an external EDID emulator, but I don't know any good DisplayPort ones.

Thank you for the reply. I am planning on migrating my workstation to Fedora in the next couple of weeks and I can inject a custom EDID image under linux regardless of what Nvidia wants to allow.

Could you please point me in the right direction regarding highjacking this function with a dumped and modded EDID image? I am a low level engineer and quite decent at reverse engineering but I have never touched monitors or EDID before so I'd appreciate a nudge in the right direction.

I have found this white paper on EDID (https://glenwing.github.io/docs/VESA-EEDID-A1.pdf) and this 1.2 DP spec (https://glenwing.github.io/docs/DP-1.2.pdf). Is "Active Off/Very Low Power" on page 14, what I should be looking at? And DP_PWR states in the DP spec (I can't find any reference to "Deep Sleep" I assume it's a marketing moniker)?
I guess the question is what mechanism in EDID/DDC is associated with this feature so I can examine it and come up with a patch for it? (Yes these Samsung monitors annoy me that much by getting continuously disconnected on sleep Smile

).

Thanks in advance!

***ToastyX*** · 11-13-2023, 10:10 PM

(11-13-2023 08:37 PM)Nodens Wrote: Thank you for the reply. I am planning on migrating my workstation to Fedora in the next couple of weeks and I can inject a custom EDID image under linux regardless of what Nvidia wants to allow.

Could you please point me in the right direction regarding highjacking this function with a dumped and modded EDID image? I am a low level engineer and quite decent at reverse engineering but I have never touched monitors or EDID before so I'd appreciate a nudge in the right direction.

I have found this white paper on EDID (https://glenwing.github.io/docs/VESA-EEDID-A1.pdf) and this 1.2 DP spec (https://glenwing.github.io/docs/DP-1.2.pdf). Is "Active Off/Very Low Power" on page 14, what I should be looking at? And DP_PWR states in the DP spec (I can't find any reference to "Deep Sleep" I assume it's a marketing moniker)?
I guess the question is what mechanism in EDID/DDC is associated with this feature so I can examine it and come up with a patch for it? (Yes these Samsung monitors annoy me that much by getting continuously disconnected on sleep ).

The issue has nothing to do with the EDID itself. The issue is the monitor is disconnecting so the system can't detect it. Changing the EDID won't change what the monitor does. The system needs to pretend the monitor is always there, which is what EDID emulation happens to do on Quadro and FirePro GPUs. If you can somehow specify a certain port on the GPU is always active with a certain EDID, that's all you need.

Nodens · (Last edited: 11-13-2023, 11:49 PM by Nodens)

(11-13-2023 10:10 PM)ToastyX Wrote:
(11-13-2023 08:37 PM)Nodens Wrote: Thank you for the reply. I am planning on migrating my workstation to Fedora in the next couple of weeks and I can inject a custom EDID image under linux regardless of what Nvidia wants to allow.

Could you please point me in the right direction regarding highjacking this function with a dumped and modded EDID image? I am a low level engineer and quite decent at reverse engineering but I have never touched monitors or EDID before so I'd appreciate a nudge in the right direction.

I have found this white paper on EDID (https://glenwing.github.io/docs/VESA-EEDID-A1.pdf) and this 1.2 DP spec (https://glenwing.github.io/docs/DP-1.2.pdf). Is "Active Off/Very Low Power" on page 14, what I should be looking at? And DP_PWR states in the DP spec (I can't find any reference to "Deep Sleep" I assume it's a marketing moniker)?
I guess the question is what mechanism in EDID/DDC is associated with this feature so I can examine it and come up with a patch for it? (Yes these Samsung monitors annoy me that much by getting continuously disconnected on sleep ).
The issue has nothing to do with the EDID itself. The issue is the monitor is disconnecting so the system can't detect it. Changing the EDID won't change what the monitor does. The system needs to pretend the monitor is always there, which is what EDID emulation happens to do on Quadro and FirePro GPUs. If you can somehow specify a certain port on the GPU is always active with a certain EDID, that's all you need.

Hmm. I think I understand something very wrong then. It was my impression that this is a monitor behavior enabled in firmware. System sends request to standby and the monitor goes into a very low energy power state which causes the system not to detect the monitor and then the slow wake up was coming from the monitor switching back into P0 state. So I was looking for means to change the power state the monitor goes in on standby without the toggle present in OSD (and without REing the monitor firmware which is probably signed anyway as it's Samsung).

From what you are telling me, the "sideeffect" issues are actually triggered by Windows? Is it that because the monitor connection was lost, Windows is triggering the PnP hot plugging behavior on wake in order to reinitialize a potentially new/different monitor device effectively causing the very slow wake and issues with multimonitor setups due to redetection? Is that correct? So by forcing EDID emulation windows just thinks the monitor is always there resulting in no side-effects?

If that is the case I can probably hack a solution for windows as well as I have a ring 0 I/O signed driver that allows me to inject anything, read/write MSRs etc (it is what I'm using for hardware readings on Realbench that I developed for Asus -- although it is compiled without the writing support there).

Thank you very much for your insights and please correct me if I got it wrong again.

EDIT: Although this probably means that on Linux just grabbing a dump of the EDID and forcing it I would not have the issues at all (assuming wayland/xwayland have the same hot plugging behavior to begin with).