>60hz refresh rate support via Extended EDID not working about virtual-display HOT 6 CLOSED

Here's the EDID I exported from my Acer Gsync monitor:

UCHAR CONST EdidAcerGSYNC[256] = {
0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x04, 0x72, 0x08, 0x04, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0x17, 0x01, 0x04, 0xA5, 0x3C, 0x22, 0x78, 0x06, 0xEE, 0x91, 0xA3, 0x54, 0x4C, 0x99, 0x26,
0x0F, 0x50, 0x54, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x56, 0x5E, 0x00, 0xA0, 0xA0, 0xA0, 0x29, 0x50, 0x30, 0x20,
0x35, 0x00, 0x80, 0x68, 0x21, 0x00, 0x00, 0x1A, 0x00, 0x00, 0x00, 0xFC, 0x00, 0x58, 0x42, 0x32,
0x37, 0x30, 0x48, 0x55, 0x0A, 0x20, 0x20, 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x5C,
0x02, 0x03, 0x0A, 0x00, 0x65, 0x4B, 0x04, 0x00, 0x01, 0x01, 0x5A, 0x87, 0x00, 0xA0, 0xA0, 0xA0,
0x3B, 0x50, 0x30, 0x20, 0x35, 0x00, 0x80, 0x68, 0x21, 0x00, 0x00, 0x1A, 0x5A, 0xA0, 0x00, 0xA0,
0xA0, 0xA0, 0x46, 0x50, 0x30, 0x20, 0x35, 0x00, 0x80, 0x68, 0x21, 0x00, 0x00, 0x1A, 0x6F, 0xC2,
0x00, 0xA0, 0xA0, 0xA0, 0x55, 0x50, 0x30, 0x20, 0x35, 0x00, 0x80, 0x68, 0x21, 0x00, 0x00, 0x1A,
0x74, 0xD2, 0x00, 0x16, 0xA0, 0xA0, 0x09, 0x50, 0x04, 0x10, 0x11, 0x00, 0x80, 0x68, 0x21, 0x00,
0x00, 0x1E, 0x1C, 0x25, 0x00, 0xA0, 0xA0, 0xA0, 0x11, 0x50, 0x30, 0x20, 0x35, 0x00, 0x80, 0x68,
0x21, 0x00, 0x00, 0x1A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x66,
};

from virtual-display.

I modded your code to load it directly, using a 256 byte ioctl instead of 128, and it loads fine but never shows anything except for 60hz refresh rates:

io_ret = DeviceIoControl(
    dev_ctx->hDevice,
    IOCTL_BVR_VMON_PLUGIN_MONITOR,
	EdidAcerGSYNC,
    256,
    NULL,
    0,
    &bytes_returned,
    NULL
    );

from virtual-display.

So, regardless of trying to send the full EDID directly, or modifying the existing code to add 120hz custom modes, they never show up. Any ideas?

from virtual-display.

Hi GoldenAxe,
You are right that LCI PROXY driver might be the road block. LCI Proxy driver only returns basic EDID data (the first 128 bytes) to OS, if I recall correctly.

LCI driver does some tricky thing when reporting [VidPnTargetMode]((https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmddi/nc-d3dkmddi-dxgkddi_vidpntargetmodeset_addmode):

1. The target modes are derived from indirectly from EDID. LCI Proxy driver skips the resolution if the size is found previousy in the set. This means that if you have 1920x1080@60 Hz and 1920x1080@120Hz in the EDID , then only the first 1920x1080 entry is populated. In this case, when the driver sees 1920x1080@120 mode, it ignores this mode because there is already a 1920x1080@60Hz in the set. You might want to remove 1920x1080@60Hz from EDID and see 1920x1080@120Hz get enumerated.

2. There is a "special hack for NVIDIA card in the driver where it always reports 60Hz refresh rate:
   // NV 210 hack. Always set VSync refresh rate = 60,000/1,000 if (PCI_DEVICE_ID(pAdapter->PciId) == PCI_DEVICE_ID_NVIDIA) { pNewTargetModeInfo->VideoSignalInfo.VSyncFreq.Numerator = 60000; pNewTargetModeInfo->VideoSignalInfo.VSyncFreq.Denominator = 1000; }
   LCI Proxy driver is not designed to report exact modes from the real monitor, since it does not actually drive the monitor. It simply cares about the dimension of the resoultion, not the refresh rate.
   You might want to try the >60Hz resolution on GPU other than NVIDIA, and make sure there is no duplicated resolution size for this particular resolution.

from virtual-display.

I didn't see that hack in your code anywhere, is it in the LCI driver code? I don't have that, that would obviously be the best place to do this. But actually, come to think of it, I'd much rather just get rid of the extra driver dependency entirely, it adds latency and shouldn't be necessary.

I tried using the EDID for the Oculus Rift which has only one detailed resolution (2160 x 1200 x 90hz), so it fits within 128 bytes when I export it from CRU, but when I reimport that into the code, it crashes vmon.exe. I guess LCI doesn't like that either.

Starting to think the only way forward here is avoiding LCI proxy. Do you think it's possible to modify the vmon driver to get rid of that dependency? I don't need hot-pluggability or even Windows 7 / 8 support.

There are some other projects out there similar to this but they are far from complete enough compared to this github, which at least works at 60hz:

https://github.com/kfroe/IndirectDisplay

from virtual-display.

Yes, the hack is in LCI driver. LCI proxy driver is the "graphics" part of the solution. It interacts with your inbox GPU driver (eg. Intel/Nvidia/AMD GPU) such that the virtual monitor appears as a physically connected monitor. Without LCI driver, you couldn't enumerate extra virtual monitor.

You can get rid of LCI driver, from Win10 RS1 or above. The "Indirect Display" driver you mentioned is the perfect example. I implemented Indirect Display driver for our company's USB Display adapter. This is definitely the way to go

By the way, when you said "vmon.exe" crash , do you mean that only the user mode app stops to work, while the system is alive ? If there is no system crash (BSOD) , it is very easy to fix the vmon.exe crash. We have nevever tested against any "stereo-scopic" monitor (such as the Oculus Rift") . I am very interested to see why vmon.exe crash. You could contact me via "[email protected]" so that I can help to address your issue.

from virtual-display.