Set custom EDID

[Zhenyu Wang]

On 2020.07.10 10:10:36 +0200, Stefan Hertrampf wrote:
> Hello,
> 
> we are developing a custom hypervisor backend for GVT which (from the mediators
> perspective) behaves like XEN.
> 
> Currently, we are working with the Linux Kernel v5.4.41 and we are trying to
> pass a custom EDID to a given vGPU.
> 
> The code flow roughly looks like this:
> 
> vgpu = intel_gvt_ops->vgpu_create();
> 
> port = intel_vgpu_port(vgpu, port);
> 
> edid_data = intel_vgpu_edid_block(port);
> 
> memcpy(edid_data, custom_edid, EDID_SIZE);
> 
> We are wondering how the set_edid callback of the intel_gvt_mpt is meant to be
> used to receive the correct port where the virtual display is attached. In
> v5.4.41 it seems, the default port is PORT_B and the mediator only calls
> set_edid on certain platforms where it is a different port. Is this correct?
> 
> Is there any other method to receive the correct port?
> 
> It seems that in v5.4.41 the mediator misses to call set_edid if the platform 
> IS_COFFEELAKE, which leads to a crash because we then assume the default PORT_B
> where no memory is allocated for the EDID data.
>

oh, I wasn't awared that actually caused crash but just thought it's a feature
enabling patch. If you like to backport, I'm fine with it.

> Also in some later commits [1] the behavior is changed and the set_edid
> callback is always called passing PORT_D. Does that mean that the virtual
> display is always attached at PORT_D on newer versions of GVT?
> 

Yes.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20200713/e49fedf8/attachment.sig>