On 2018.09.10 12:43:04 +0200, Gerd Hoffmann wrote:
> 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.
>
Then that should be fine. Current intel display driver has 5 hotplug
irq threshold within one second.
> > > 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?
>
I need to double check this with our display developer on current supported HW.
> > > +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).
>
thanks
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
Attachment:
signature.asc
Description: PGP signature
