Cursor size 128x128

[z0Kng]

I noticed that in a recent commit:
https://github.com/intel/Display-Virtualization-for-Windows-OS/blame/47de3c4ef55a1c826332955cb40f2caef9bd4789/DVServerKMD/helper.h#L86
the cursor size was increased to 128×128, which is a welcome change especially for higher resolutions and for users who scale their cursor.

However, this appears to conflict with the virtio-gpu specification, which currently enforces a 64×64 cursor size.
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-4040006

Because of this mismatch, the cursor appears corrupted when using stock QEMU.

I also found this commit in your Intel-distribution-of-QEMU repository which mitigates the issue:
intel/Intel-distribution-of-QEMU@fa3963d

However, I’m not sure whether a change like this would be accepted upstream in QEMU.

Are there any plans to make this compatible with upstream QEMU? For example:

• proposing a patch to QEMU,
• updating the virtio specification to allow larger cursor sizes, or
• adding a compatibility fallback for 64×64 cursors?

I’d be interested to hear what the intended long-term approach is.

[downor]

intel/Intel-distribution-of-QEMU@fa3963d

This is a code change to make it work with various cursor size on windows VM as you see. We don't have any plan to upstream it for now.

[z0Kng]

Thanks for the answer.

I also noticed another issue: the resolution of the client (in our case, Spice/Remoteviewer, but probably also the gtk) does not get applied into the VM, for example, if the client gets resized.

The issue seems to be that

Display-Virtualization-for-Windows-OS/DVServerUMD/DVServer/DVServeredid.cpp

Line 107 in 47de3c4

monitor->ulPreferredModeIdx = 0;

is hardcoded to 0 but

Display-Virtualization-for-Windows-OS/EDIDParser/edidparser.c

Line 47 in 47de3c4

get_detailed_timing_descriptor_modes(edid_data, kmd_modelist);

does not get parsed first.
Moving the detailed timings beeing parsed first, solves the problem temporarily until to many resizes happen, and the windows registry gets to full of different monitors (due to the hotplug and a new edid every time) and windows no longer applies the preferred resolution.

Is this a know isssue? Are the plans to fix it or can/should we do a pr?

[malayaku]

Sorry for the delayed response on the second issue mentioned here.

I want to make sure I understand the issue correctly. Are you suggesting that the DTD (Detailed Timing Descriptor) modes should be parsed first, so that: monitor->ulPreferredModeIdx = 0; always points to the DTD mode, which is typically the monitor's preferred/native resolution?
If so, are you proposing that the parsing order be changed as follows?

parse_edid_data (current)
get_timing_bitmaps_modes(edid_data, kmd_modelist);
get_standard_modes(edid_data, kmd_modelist);
get_cea_modes(edid_data, kmd_modelist);
get_detailed_timing_descriptor_modes(edid_data, kmd_modelist);
get_additional_standard_display_modes(edid_data, kmd_modelist);

parse_edid_data (proposed)
get_detailed_timing_descriptor_modes(edid_data, kmd_modelist);
get_timing_bitmaps_modes(edid_data, kmd_modelist);
get_standard_modes(edid_data, kmd_modelist);
get_cea_modes(edid_data, kmd_modelist);
get_additional_standard_display_modes(edid_data, kmd_modelist);

[z0Kng]

So what I'd like to achieve is this:

Screencast_20260805_102255.webm

The user changes the window size of the VM, and then the resolution inside the VM is adjusted. till, users should be able to select a resolution from a list of available options; otherwise, a feature would be lost here, and I don't think you'd merge that. Now I was wondering if you might already be working on this, since it would definitely be useful to have. And if not, would you be interested in having it added?

I've already experimented quite a bit and tried several different approaches, but so far none of them have convinced me 100%.

• 1 The approach you mentioned
  This only works for a limited number of resolution changes. Windows treats every hotplug event with a new resolution as a completely new monitor, which ends up filling the registry with monitor entries. After a while, Windows no longer applies the correct resolution because of all those stale entries. In theory, we could clean up the registry ourselves, but that doesn't feel like the right solution. Another downside is that every hotplug event causes the user's open application windows to be moved around, minimized, or otherwise rearranged.

• 2 Avoiding hotplug and using IddCxMonitorUpdateModes instead
  I initially had a lot of trouble getting this approach to work. At first, it only worked when I exposed a single resolution, which meant the user could no longer choose from a predefined list of resolutions. I've now got it working reasonably well (see the video above) by creating a fake monitor. I'm still not completely satisfied with the implementation, but it has two major advantages: application windows stay exactly where they are, and it doesn't spam the registry with new monitor entries.

Have any of you had any experience with this, or do you have another idea that I might have overlooked?

[malayaku]

Thanks for sharing the details. I have a couple of questions to better understand the limitations you're seeing.

Regarding the hotplug approach:
"Windows treats every hotplug event with a new resolution as a completely new monitor, which ends up filling the registry with monitor entries. After a while, Windows no longer applies the correct resolution because of all those stale entries."

I'm not sure I fully understand this part. Do you mean that after multiple resize operations, the resolution change eventually starts failing because Windows selects an incorrect monitor instance or mode from the accumulated registry entries?

Also, regarding the second approach:
"I've now got it working reasonably well by creating a fake monitor. I'm still not completely satisfied with the implementation."

Could you elaborate a bit more on the reason behind creating the fake monitor? Does this fake monitor also appear as an additional display in Windows Display Settings, or is it only used internally to make IddCxMonitorUpdateModes() work correctly?

From our side, the current design is as follows:
Whenever the VM window is resized, QEMU signals a display change interrupt with updated EDID information.
The mode list remains the same, and only the preferred timing (DTD) changes.
Since an EDID change is generally interpreted as a monitor change, our driver currently treats the resize event as a HPD event.
Based on that assumption, the existing flow appears to work correctly, and so far we have not observed any issues.

If the main concern is only updating the preferred resolution (DTD) while preserving the existing monitor instance, we could explore a more targeted fix. For example, we may be able to pass the DTD index from the EDID parser to the UMD and handle preferred mode updates without going through the full hotplug path.

It would be helpful to better understand the specific issues you're seeing with the current flow, especially the resolution application failures and the motivation for the fake-monitor approach.

[z0Kng]

So the behavior I'm currently seeing with the existing driver:

Screencast_20260806_153630.webm

When I resize the window, it does the hotplug, but Windows always sets the resolution to 1024x768 because that's the first resolution in the list, and ulPreferredModeIdx is hardcoded to 0. As you can see in the video, the new resolution appears as selectable but is not automatically applied. If you resize on your setup, is the new resolution automatically applied?

So the first fix I had in mind was moving
get_detailed_timing_descriptor_modes(edid_data, kmd_modelist);
so that the first resolution is always the preferred one. That works for some time; Windows correctly applies the resolution for some time. But after a few resolution changes, it no longer applies the preferred resolution, aka the client window resolution, but an arbitrary one. And what i noticed is that for each hotplug, new registry entries are created (see picture in the post above), and if I delete them, it works again for some time.

So I began to testing with IddCxMonitorUpdateModes but that seems to be bugged if only one monitor is there. So I created it for testing a fake monitor from within th idd that appears in Windows, and with that, it worked correctly as I wanted it (see video in previous post). I need to do more testing here.

[malayaku]

I performed a few experiments using the following PowerShell script to check whether the registry key counts change during a true HPD event versus a resize event (false HPD case).

$base = "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers"
@("Configuration", "Connectivity", "ScaleFactors") | ForEach-Object {
$path = Join-Path $base $_
if (Test-Path $path) {
$count = (Get-ChildItem $path).Count
Write-Host "$_ : $count"
}
else {
Write-Host "$_ : Not Found"
}
}

During a true HPD scenario, I did not observe any change in the registry key counts.
However, during a resize operation (which appears to be a false HPD case), the registry key counts increased. For every resize operation, the counters increased as follows:

Configuration: +2
Connectivity: +1
ScaleFactors: +1

Based on these observations, there appear to be a few possible options:

1. Detect false HPD events and avoid taking any action

In this approach, we would not consume the new EDID or perform mode detection for a false HPD event. Instead, we would continue using the existing resolution. However, I do not think this option will fully address your issue.

To identify a false HPD case, we can comment out the else if section below:

} else if (hdata.screen_present[count]) {
if (get_edid_data(g_DevInfo->get_Handle(), &g_monitors[count], count, d_edid) ==
DVSERVERUMD_FAILURE) {
ERR("QEMU EDID initialization failed, falling back to default IDD EDID");
get_edid_data(g_DevInfo->get_Handle(), &g_monitors[count], count, TRUE);
}
if (memcmp(minfo[count].pEdidBlock, g_monitors[count].pEdidBlock, minfo->szEdidBlock) != 0) {
DBGPRINT("EDID changed for display = %d\n", count);
// Reset the edid block and copy the new edid block
memset(minfo[count].pEdidBlock, 0, minfo[count].szEdidBlock);
memcpy_s(minfo[count].pEdidBlock, minfo->szEdidBlock, g_monitors[count].pEdidBlock,
minfo->szEdidBlock);
// Remove the display and connect it again with fresh EDID
IddCxMonitorDeparture(g_monitorobject_list[count]);
g_monitorobject_list[count] = NULL;
pDeviceContextWrapper->pContext->FinishInit(count);
do_set_event = TRUE;
}
}

2. Modify QEMU to send a stable EDID

Another option is to make code changes on the QEMU side so that it provides a stable EDID. However, I do not believe this option will significantly help with your issue.

3. Add registry cleanup logic in DVEnabler

We can periodically clean up stale registry entries from DVEnabler to prevent the continuous growth of registry keys.

4. Evaluate IddCxMonitorUpdateModes

I have not yet investigated the IddCxMonitorUpdateModes option. This is another area that needs further evaluation.

[z0Kng]

Thank you for looking into the problem.

Option 1&2
would fix the registry spam but would make it impossible to set the client resolution in the guest VM, so as you said, not what I wanted.

Option 3
would definitely work, but feels a bit like a workaround. It also has the problem when resizing that windows will move the windows of applications around due to the monitor disappearing for a short amount of time. But still, it would work.

Option 4
Could lead to the best results if working correctly; however, I still need to investigate why it does not work correctly for me without an additional fake monitor. So I will investigate further on this.

[malayaku]

Instead of starting from scratch, could you share what you've done so far with IddCxMonitorUpdateModes? I'll review it and see whether you're on the right track, and help with any corrections or next steps.

[z0Kng]

sure, I will clean it up from dead code and send it to you tomorrow.

[z0Kng]

Here it is: https://github.com/opensourcevdi/Display-Virtualization-for-Windows-OS/tree/IddCxMonitorUpdateModes_tests
still early testing and a bit of a playground.

I moved the edid parsing, added IddCxMonitorUpdateModes and refactored the DVEnabler a bit so that it will apply the resolution.

And thats what I meant with add a fake monitor if there is only one, otherwise it does not work for me. Still have to figure out why.

[z0Kng]

Ok I think I fixed all the issues. The issue with the additional monitor needed was due to Windows source/target modes. This could be fixed via SDC_FORCE_MODE_ENUMERATION see: opensourcevdi@4f3c546

I then ran into another issue, that windows would still reject the resolution due to the monitor not supporting the resolution. I fixed this by patching the edid supplied from qemu see: opensourcevdi@e6d9db1. I know that's a bit strange to do this here and not in qemu, but we know our idd can do all resolutions, so I think it's reasonable to do it there.

I then also clamped the result to the supported resolutions by the KMD see: opensourcevdi@75f6a61 There I noticed that KMD and UMD have different limits. Is there a reason for that? I changed it to the KMD limits.

I will still do some clenaup before I can do a PR, but so far do you see any issues with this approach?

[malayaku]

Thanks for the commits. Since these look like substantial changes, I’ve asked my teammate to review them. She will validate the updates and share her feedback here shortly.

[varsha-manimaran]

We tried the changes and saw some issues:

1. With multimonitor, by default the additional monitors seems to go into duplicate mode instead of extend (which is the expectation).
2. There is an additional resolution in the drop down: 800x600. Switching to this resolution causes a display corruption
3. The preferred resolution set by the user is not retained post VM reboot

Are you seeing the same issues at your end?

Additionally, we recently renamed the product so we recommend that you rebase your branch onto the latest master.

[z0Kng]

Thank you very much for the feedback. I can confirm that I can reproduce all the issues. I will fix them and will rebase it and then make an PR.
However, this might take some time, as I am currently on vacation.