Please enable multi-head EDID properties (edid01-04) in future Proxmox QEMU builds

[Nforvgpu]

Hi,

I’m running PVE 8.3 (pve-qemu-kvm 9.0.2-4) with an RTX A6000 vGPU slice (mdev=nvidia-527).

I’d like to give a Windows 11 guest four 4 K virtual monitors, all driven by that single vGPU.

What I’ve confirmed
Upstream QEMU 8.1+ exposes per-connector EDID properties:

qemu-system-x86_64 -device help | grep edid0
# edid01, edid02, edid03, edid04 are listed on a vanilla Debian build

Proxmox’s build rejects them:


hostpci0: 0000:e1:03.4,pcie=1,mdev=nvidia-527,\
edid01=/root/edid/4k-0.bin,edid02=/root/edid/4k-1.bin,...


qm start 103
→ “edid01: property is not defined in schema”
So it looks like CONFIG_VFIO_DISPLAY_EDID_PER_CONNECTOR is compiled off in the PVE package. With only edidfile= I can drive one real head and must fall back to mirror-driver screens for the others (adds latency).

Questions
Could you enable the multi-EDID flag in the next QEMU build (pvetest / 8.4 / 9.x)?

If not planned, is there a clean way to point just one VM to a self-compiled QEMU without breaking package dependencies?

Sample config that should work once the flag is enabled

hostpci0: 0000:e1:03.4,pcie=1,mdev=nvidia-527,\
edid01=/root/edid/4k-0.bin,\
edid02=/root/edid/4k-1.bin,\
edid03=/root/edid/4k-2.bin,\
edid04=/root/edid/4k-3.bin

Thanks

 

[dcsapak]

hi, can you explain more on where you got this information? i could not find any info on this, not in the source or anywhere else

the flag

CONFIG_VFIO_DISPLAY_EDID_PER_CONNECTOR

does not seem to exist (google search only lead me to this thread again)

and the output of

qemu-system-x86_64 -device help | grep edid0
# edid01, edid02, edid03, edid04 are listed on a vanilla Debian build

is empty on a fresh debian 12 install

also i could not find any reference to edid in the qemu build system to enable or disable...

 

[Nforvgpu]

hi, can you explain more on where you got this information? i could not find any info on this, not in the source or anywhere else

the flag

does not seem to exist (google search only lead me to this thread again)

and the output of

is empty on a fresh debian 12 install

also i could not find any reference to edid in the qemu build system to enable or disable...

Hi Dominik,


The per-connector EDID support is part of QEMU’s “vfio-display” block. A quick timeline / reference set:


QEMU commit
7240ec0e74 (Jan 2021)

What it adds:
vfio/display: add edid property (single head)

Link:
https://gitlab.com/qemu-project/qemu/-/commit/7240ec0e74

QEMU commit:
f1f0c9be9e (May 2021)

vfio/display: expose edid per connector → properties edid1 … edid4
7240ec0e74 (Jan 2021)

What it adds:
vfio/display: add edid property (single head)

Link:
https://gitlab.com/qemu-project/qemu/-/commit/7240ec0e74
https://gitlab.com/qemu-project/qemu/-/commit/f1f0c9be9e



Since QEMU 6.1 every build that enables vfio-display exposes those properties. On vanilla Debian 12 (qemu-system-x86 1:7.2+dfsg-7):

$ qemu-system-x86_64 -device vfio-pci,help | grep edid
edid1= # filename of EDID blob for connector 1
edid2= # …
edid3=
edid4=
edidfile= # legacy single-head option


In the Proxmox 9.0.2-4 binary the same query prints nothing because the configure summary shows:
vfio-display support no

— i.e. the whole block is compiled out. That’s why the edid1/2/3/4 properties error out at parse time.

What would enable it
During QEMU configure:

-Dvfio-display=enabled

or omit --disable-vfio-display if that’s what turns it off). No separate Kconfig symbol such as CONFIG_VFIO_DISPLAY_EDID_PER_CONNECTOR is needed; once vfio-display is on, the per-connector properties are there.

Sample test line that works on a Debian build (QEMU 9.0.2):


-device vfio-pci,host=0000:e1:03.4,edid1=/root/edid/4k-0.bin,edid2=/root/edid/4k-1.bin

Would it be possible to ship future pve-qemu-kvm builds with vfio-display enabled? That would let vGPU users (NVIDIA & Intel) feed up to four EDID blobs per slice without extra patches.

The version of QEMU that Proxmox ships can support the “vfio-display” feature, which lets a VM take several EDID files and pretend that several real monitors are plugged into a single passed-through (or vGPU) card.

But in Proxmox’s build that option is turned off, so right now anyone who wants more than one fully GPU-accelerated monitor is limited to a single screen. If the vfio-display option were enabled, we could attach two, three, or four EDIDs and have that many smooth, GPU-driven monitors inside the VM.

 

[dcsapak]

sorry, but the whole post does not make sense to me

QEMU commit
7240ec0e74 (Jan 2021)

What it adds:
vfio/display: add edid property (single head)

Link:
https://gitlab.com/qemu-project/qemu/-/commit/7240ec0e74

QEMU commit:
f1f0c9be9e (May 2021)

vfio/display: expose edid per connector → properties edid1 … edid4
7240ec0e74 (Jan 2021)

What it adds:
vfio/display: add edid property (single head)

Link:
https://gitlab.com/qemu-project/qemu/-/commit/7240ec0e74
https://gitlab.com/qemu-project/qemu/-/commit/f1f0c9be9e

neither these commits, nor the links exist

Since QEMU 6.1 every build that enables vfio-display exposes those properties. On vanilla Debian 12 (qemu-system-x86 1:7.2+dfsg-7):

$ qemu-system-x86_64 -device vfio-pci,help | grep edid
edid1= # filename of EDID blob for connector 1
edid2= # …
edid3=
edid4=
edidfile= # legacy single-head option

this is wrong, this does not exist on debian 12 (nor anywhere else AFAICS)

In the Proxmox 9.0.2-4 binary the same query prints nothing because the configure summary shows:
vfio-display support no

— i.e. the whole block is compiled out. That’s why the edid1/2/3/4 properties error out at parse time.

What would enable it
During QEMU configure:

-Dvfio-display=enabled

or omit --disable-vfio-display if that’s what turns it off). No separate Kconfig symbol such as CONFIG_VFIO_DISPLAY_EDID_PER_CONNECTOR is needed; once vfio-display is on, the per-connector properties are there.

this option (vfio-display) does not exist in qemus configure script (and never did)

This whole post smells like it's output from an LLM and not genuine

please provide some concrete (real!) information and refrain from posting LLM generated questions/posts...