Hi,
> > Intel has two hard-coded edid blobs for that (depending on vgpu type).
> > Not sure how nvidia handles this, but probably simliar. With qemu passing a
> > edid blob for the virtual display instead of using the hardcoded blob we could
> > make the display configuration much more flexible.
>
> Sounds interesting. People are asking us to add more display modes. With this
> proposal, we could provide any required mode in a flexible way.
Yes, exactly.
> But the hard-coded resolution might still be needed. As it is used for vgpu
> resources allocation during vgpu creation before running a qemu. And a
> vgpu cannot support a resolution bigger than the one used for its resources
> allocation.
The CAPS ioctl below should handle that:
> > +/**
> > + * VFIO_DEVICE_GFX_EDID_CAPS - _IOW(VFIO_TYPE, VFIO_BASE + 17,
> > + * struct vfio_device_gfx_edid_caps)
> > + *
> > + * Get edid capabilities.
> > + *
> > + * Drivers must support either none or both GFX_EDID ioctls,
> > + * so the CAPS ioctl can also be used to probe for edid support.
> > + *
> > + * max_xres, max_yres - maximum display resolution supported.
> > + * value "0" means no restriction.
> > + *
> > + */
> > +struct vfio_device_gfx_edid_caps {
> > + __u32 argsz;
> > + __u32 flags;
> > + /* out */
> > + __u32 max_xres;
> > + __u32 max_yres;
> > +};
cheers,
Gerd
