From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753890AbdKIUzD (ORCPT ); Thu, 9 Nov 2017 15:55:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56596 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbdKIUzC (ORCPT ); Thu, 9 Nov 2017 15:55:02 -0500 Date: Thu, 9 Nov 2017 13:54:57 -0700 From: Alex Williamson To: Gerd Hoffmann Cc: Tina Zhang , chris@chris-wilson.co.uk, joonas.lahtinen@linux.intel.com, zhenyuw@linux.intel.com, zhiyuan.lv@intel.com, zhi.a.wang@intel.com, kevin.tian@intel.com, daniel@ffwll.ch, kwankhede@nvidia.com, hang.yuan@intel.com, intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, linux-kernel@vger.kernel.org, Daniel Vetter Subject: Re: [PATCH v17 5/6] vfio: ABI for mdev display dma-buf operation Message-ID: <20171109135457.4f7514d3@t450s.home> In-Reply-To: <20171109183514.w3tbqumovglr4sri@sirius.home.kraxel.org> References: <1510220042-4931-1-git-send-email-tina.zhang@intel.com> <1510220042-4931-6-git-send-email-tina.zhang@intel.com> <20171109082956.2c490080@t450s.home> <20171109183514.w3tbqumovglr4sri@sirius.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 09 Nov 2017 20:55:02 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Nov 2017 19:35:14 +0100 Gerd Hoffmann wrote: > Hi, > > > struct vfio_device_gfx_plane_info lacks the head field we've been > > discussing. Thanks, > > Adding multihead support turned out to not be that easy. There are > corner cases like a single framebuffer spawning both heads. Also it > would be useful to somehow hint to the guest which heads it should use. > > In short: Proper multihead support is more complex than just adding a > head field for later use. So in a short private discussion with Tina we > came to the conclusion that it will be better add multihead support to > the API when the first driver wants use it, so we can actually test the > interface and make sure we didn't miss anything. Adding a incomplete > multihead API now doesn't help anybody. Do you think we can enable multi-head and preserve backwards compatibility within this API proposed here? Thanks, Alex