Threaded Mode | Linear Mode

***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: 253)

***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: 271)

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

***ToastyX*** · 11-14-2023, 01:55 AM

(11-13-2023 11:44 PM)Nodens Wrote: 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).

It is monitor behavior controlled by the firmware. The problem is the monitor is not supposed to disconnect when sleeping, and it shouldn't be slow to wake up. This is a flaw in the monitor, not something you can change unless you can edit the firmware somehow.

I think you're getting confused because you saw DPMS has four power states with one coincidentally described as deep sleep, but DPMS is an old standard that was deprecated 20 years ago and replaced by DPM, which only has two power states: on and off (sleep/standby). Windows only implements those two power states, so the power state information in the EDID isn't relevant.

The issue you're having with the monitor is unrelated to power states. It's a design issue with the monitor also complicated by the way DisplayPort works. VGA, DVI, and HDMI use DDC, and DDC is powered by the source so the EDID can be read even if the monitor is turned off. DisplayPort monitors basically emulate DDC through the AUX channel, which disconnects when the monitor is turned off, but most monitors will stay connected while sleeping. The "deep sleep" option you talked about is a setting some monitors offer to use less power while sleeping, but it has the side effect of disconnecting as if the monitor were turned off. I guess you are saying your monitor does that with no option to disable that behavior.

(11-13-2023 11:44 PM)Nodens Wrote: 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?

You didn't say what side effects you're seeing, but issues like windows resizing or moving to another monitor or hearing the device disconnect/reconnect sounds are side effects of Windows responding to the monitor disconnecting. So yes, emulating the EDID so Windows thinks the monitor is always there will work around those issues.

Nodens · (Last edited: 11-14-2023, 08:46 PM by Nodens)

(11-14-2023 01:55 AM)ToastyX Wrote: It is monitor behavior controlled by the firmware. The problem is the monitor is not supposed to disconnect when sleeping, and it shouldn't be slow to wake up. This is a flaw in the monitor, not something you can change unless you can edit the firmware somehow.

I was afraid this may be the case. The monitors we're talking about are 2x Samsung Odyssey G7 32" (SKU: LC32G75TQSUXEN).

Quote:I think you're getting confused because you saw DPMS has four power states with one coincidentally described as deep sleep, but DPMS is an old standard that was deprecated 20 years ago and replaced by DPM, which only has two power states: on and off (sleep/standby). Windows only implements those two power states, so the power state information in the EDID isn't relevant.

Basically I was looking at page 110 of the DP 1.2 spec document. Where it describes:

Code:

In D0 state, a Sink device may disable DP_PWR

– Sink device is OFF (or reset) or not monitoring Source Detection signal

– Sink device de-asserts HPD signal

– Sink device may go to D1 state any time

– Sink device may go to D0’ state if it supports Source Detect feature and Source device is not

detected

• In D0’ state, a Sink device must enable DP_PWR (For a tethered Sink device, upon detecting

DP_PWR Consumer)

– Sink device de-asserts HPD signal, but monitors Source Detect status

– Sink device goes to D1 when Source detected

• Sink device may go to D0 state any time

• In D1 and D2 states, a Sink device must enable DP_PWR (For a tethered Sink device, upon detecting

DP_PWR Consumer)

– Sink device asserts HPD signal

– Sink device is either receiving or ready to receive bits over Main Link

– Sink device goes to D0’ state when Source is absent

– Sink device stays in D1 even when Source writes 2 to Address 600h

• Sink device may go to D0 state any

Quote:The issue you're having with the monitor is unrelated to power states. It's a design issue with the monitor also complicated by the way DisplayPort works. VGA, DVI, and HDMI use DDC, and DDC is powered by the source so the EDID can be read even if the monitor is turned off. DisplayPort monitors basically emulate DDC through the AUX channel, which disconnects when the monitor is turned off, but most monitors will stay connected while sleeping. The "deep sleep" option you talked about is a setting some monitors offer to use less power while sleeping, but it has the side effect of disconnecting as if the monitor were turned off.

Is this not the mechanism described above? That in D0 the monitor is allowed to do that according to spec? Or I'm reading that wrong? (The spec is huge so I'm searching through parts that seem related at his point).

Quote: I guess you are saying your monitor does that with no option to disable that behavior.

Yes this is exactly what it does. According to my research most monitors that exhibit this behavior have an OSD option to toggle it. These monitors do not.

(11-13-2023 11:44 PM)Nodens Wrote: You didn't say what side effects you're seeing, but issues like windows resizing or moving to another monitor or hearing the device disconnect/reconnect sounds are side effects of Windows responding to the monitor disconnecting. So yes, emulating the EDID so Windows thinks the monitor is always there will work around those issues.

Indeed I neglected that, my bad. The 2 main issues I am experiencing are these:

1) When monitors go to sleep they need about 8-12 seconds in order to wake up and they do what looks like a "double" wake up (blanking and re-initializing), the second one being shorter, which results in like 12-15 seconds total delay. Initially I didn't mind this but it has started being extremely annoying specially when I'm in a hurry and I have to wait for the monitors in order to eg send that email I almost forgot while I'm already late for an appointment. Also depending on the Nvidia driver sometimes this results in a weird error involving explorer.exe (maximized windows not factoring the taskbar on the the Y axis and the bottom of the maximized window landing behind it) or, extremely rarely, re-arranged desktop icons (I have a workaround for that so this is the least of my worries).

2) The second monitor, that is on my left side is also connected to my homelab Fedora server, which I usually administrate headless via ssh but sometimes I need to do things there that are *much* faster with a GUI (eg diffing big configuration files with Kompare). If I have the monitor on the HDMI and it goes on sleep while I work on my workstation on the main monitor, when it wakes up it does so *much* faster, not doing the second wake (no blanking and reinit--a total of 4-5sec), BUT causes the main monitor to do it instead. I assume this is also related to the monitor's deep sleep behavior as I think it triggers HPD on the the DP port as well, on wake, which in turn triggers a PNP re-detection in Windows.

I really like these monitors in general but this behavior has gotten extremely old in a year of using them.

jeffeh12133 · (Last edited: 11-15-2023, 10:26 PM by jeffeh12133)

(11-14-2023 01:55 AM)ToastyX Wrote:
(11-13-2023 11:44 PM)Nodens Wrote: 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).
It is monitor behavior controlled by the firmware. The problem is the monitor is not supposed to disconnect when sleeping, and it shouldn't be slow to wake up. This is a flaw in the monitor, not something you can change unless you can edit the firmware somehow.

I think you're getting confused because you saw DPMS has four power states with one coincidentally described as deep sleep, but DPMS is an old standard that was deprecated 20 years ago and replaced by DPM, which only has two power states: on and off (sleep/standby). Windows only implements those two power states, so the power state information in the EDID isn't relevant.

The issue you're having with the monitor is unrelated to power states. It's a design issue with the monitor also complicated by the way DisplayPort works. VGA, DVI, and HDMI use DDC, and DDC is powered by the source so the EDID can be read even if the monitor is turned off. DisplayPort monitors basically emulate DDC through the AUX channel, which disconnects when the monitor is turned off, but most monitors will stay connected while sleeping. The "deep sleep" option you talked about is a setting some monitors offer to use less power while sleeping, but it has the side effect of disconnecting as if the monitor were turned off. I guess you are saying your monitor does that with no option to disable that behavior.

(11-13-2023 11:44 PM)Nodens Wrote: 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?
You didn't say what side effects you're seeing, but issues like windows resizing or moving to another monitor or hearing the device disconnect/reconnect sounds are side effects of Windows responding to the monitor disconnecting. So yes, emulating the EDID so Windows thinks the monitor is always there will work around those issues.

Hey, I have a quick question. I currently use a Acer XB253Q GP via DisplayPort. I've been messing around with CRU and I noticed that, by default, my native resolution is detailed 1920x1080 @ 60hz but it seems like there is also a duplicate 1920x1080 @ 60hz under standard. This is all default. Why is this? Should I delete the "standard" 1920x1080@60 and leave the detailed one? what is the difference exactly? i'm confused. I deleted one and been trying out some games and it looks/feels different. I dont understand why

also wanted to thank you tremendously for not only providing an amazingly useful tool, but also having the patience to hang around and answer any technical questions. you are a guru!

Poilaucul · (Last edited: 11-16-2023, 12:16 AM by Poilaucul)

Hi,

A bit of context first, I use OBS to stream my desktop via display capture source, the stream is running almost 23/5, as you can imagine sometimes I'm not active on the computer and during that time I use Display Power Off Utility to trigger Windows turning my displays off, this has the advantage of being instantaneous and most importantly not modifying the placement of my opened windows when I get back on the computer, and that's really important to me.

The issue I'm facing is during the time my screen is off programs that are in foreground have their graphics frozen and I would want them to refresh as if I was one the computer screen on.

Everything works perfectly as I want it to when I turn my screen off via their power buttons (but still powered via wall socket)....until DisplayPort rapid hot plug detect kicks messes everything up.

You can learn more about the issue there
https://www.datapro.net/techinfo/hot_plu...ction.html
https://hackaday.io/project/170643-edido...rt-hotplug

So, I looked for solutions to keep my displays attached while powered off, so far it's either:

- Buy an hardware EDID stopper, which doesn't support 4K@60fps
- Buy a Quadro GPU to do EDID emulation of connected display
- Have CRU do it

Last solution is my favorite but frankly I don't know what the f I'm doing, and I don't even know if CRU can do what I want so I need your help guys please.

How do I set CRU to stop Windows from disconnecting my displays when I turn them off?