Messages in this thread | | | Date | Mon, 17 Sep 2018 17:15:50 +0800 | From | Zhenyu Wang <> | Subject | Re: [PATCH 1/2] vfio: add edid api for display (vgpu) devices. |
| |
On 2018.09.17 10:50:33 +0200, Gerd Hoffmann wrote: > > > +#define VFIO_DEVICE_INFO_CAP_EDID 1 > > > + > > > +struct vfio_device_info_edid_cap { > > > + struct vfio_info_cap_header header; > > > + __u32 max_x; /* Max display height (zero == no limit) */ > > > + __u32 max_y; /* Max display height (zero == no limit) */ > > > +}; > > > > As current virtual display for Intel vGPU is still emulating against real HW > > pipeline with same limitations, asked display developers that whether or not > > specific mode can work might still depend on current or future HW behavior. > > So could we add some hints on what kind of edid mode vfio device can operate? > > Some may support arbitrary modes, but some may only support standard modes. > > What kind of restrictions do we have here? Really to a fixed list of > standard modes?
Restriction is still with HW differences, e.g for skl/kbl with ddi wrpll within min/max clock range which may generate any required frequency, but I've been told for bxt there're some gaps in clock range that could be generated.
> > Some testing (kaby lake) indicates y axis has no restrictions and x axis > gets rounded up to the next multiple of 8 pixels (32 bytes), maybe to > align scanlines with cachelines?
That should be plane stride requirement I think.
> > Oh, and btw: Seems the resolution restriction (to 1024x768 for the > smallest vgpu type) seems to not be enforced. Intentional? >
hmm, what do you mean here? Not enforce to have only one mode for vgpu type? Or can't change to other mode?
-- Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 [unhandled content-type:application/pgp-signature] | |