Hi,
> > Ideally qemu would also be able to update the edid blob at any time, and
> > the vgpu will notify the guest about it (probably by emulating a monitor
> > hotplug event). The guest can react on qemu window resizing then and
> > adapt automatically, simliar to how it works with qxl and virtio-gpu.
>
> What's the frequency for those edid update during resizing? Looks it's
> possible to bring hotplug storm that I'm not sure if all guest drivers
> for gvt has proper handling.
At most once per second.
The window resize typically creates a flood of the these events. qemu
doesn't forward them to the guest as-is, but instead sets up a timer,
firing one second later. The next event coming in just rearms the
timer. When the timer goes off the guest is actually notified.
> > The guest and the vgpu should be able to handle "odd" non-standard
> > display resolutions like this (coming from random window resizing):
> >
> > Detailed mode: Clock 106.620 MHz, 477 mm x 330 mm
> > 1212 1515 1551 1636 hborder 0
> > 840 844 848 869 vborder 0
> > -hsync -vsync
> > VertFreq: 74 Hz, HorFreq: 65171 Hz
> >
>
> Some odd timing might not be supported, e.g can't get a sane PLL setting
> calculation for clock required. As gvt exposes a virtual display pipeline
> following hw definition, so guest driver still depend on sane output, I
> think that may just go wrong with arbitrary mode..
I've suspected that might become an issue.
What kind of restrictions exist for the clock?
> > +struct vfio_device_gfx_edid_set {
> > + __u32 argsz;
> > + __u32 flags;
> > + /* in */
> > + __u8 edid[256];
> > +};
> > +
>
> I assume you have defined return value for the set too right? In case
> for driver can't handle or invalid edid blob, etc.
Just return -EINVAL then, as usual (but I can update the comment
explicitly saying so).
cheers,
Gerd
