Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 17 Sep 2018 12:13:55 +0200
From:   Gerd Hoffmann <kraxel@redhat.com>
To:     Zhenyu Wang <zhenyuw@linux.intel.com>
Cc:     Alex Williamson <alex.williamson@redhat.com>,
        Kirti Wankhede <kwankhede@nvidia.com>,
        intel-gvt-dev@lists.freedesktop.org,
        open list <linux-kernel@vger.kernel.org>, kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] vfio: add edid api for display (vgpu) devices.
Message-ID: <20180917101355.pfk2bbmgdwabcyqc@sirius.home.kraxel.org>
References: <20180913054745.6353-1-kraxel@redhat.com>
 <20180913054745.6353-2-kraxel@redhat.com>
 <20180913115139.02775316@t450s.home>
 <20180914122552.3xmepqo7azzmx7ky@sirius.home.kraxel.org>
 <20180917065154.GI20737@zhen-hp.sh.intel.com>
 <20180917085033.ttcs3cpznnf3wngd@sirius.home.kraxel.org>
 <20180917091550.GK20737@zhen-hp.sh.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180917091550.GK20737@zhen-hp.sh.intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Sep 17, 2018 at 05:15:50PM +0800, Zhenyu Wang wrote:
> 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.

Ok, handling min/max clock (pixel clock I assume) should be easy.
Ranges are more difficuilt ...

But shouldn't the guest driver be able to cope with modes which can't be
displayed?  Monitors don't adjust edid to display driver capabilities
either, so the non-working modes are probably simply dropped from the
list of monitor modes ...

> > 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?

Using i915-GVTg_V5_8 type.  Description says "resolution: 1024x768".
The edid data lists 640x480, 800x600, 1024x768.

I can set modes higher than 1024x768 though.  Can create custom modes
(using xrandr --newmode), attach them to the output (xrandr --addmode)
and activate them (xrandr --mode).

cheers,
  Gerd