Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Alex Williamson <alex.williamson@redhat.com>]

On Tue, 07 Nov 2017 09:03:21 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > > Add a head field here?  People asked @ kvm forum about multihead
> > > support.
> > > Even if the initial driver version doesn't support it we could add
> > > a field so it
> > > becomes easier to add it at some point in the future.
> > > 
> > > Probing for available heads could be done with the PROBE flag, i.e.
> > > flags = PROBE | DMABUF, plane_type = PRIMARY, head = 0, 1, ...  
> > 
> > Does the multihead mean multiple display monitor? So each head can
> > have its own one primary plane, one cursor plane and maybe some
> > sprite planes if supported.  
> 
> Yes and yes.
> 
> > And the flow could be like this:
> > 1) flags = PROBE | DMABUF, then return the number of heads in
> > vfio_device_gfx_plane_info.head.  
> 
> I'd suggest to use { .flags = PROBE | DMABUF, .head = 0 } to check
> whenever dmabuf is supported for head 0, then { .flags = PROBE |
> DMABUF, .head = 1 } to check for head 1 support, ...
> 
> Driver returns success if the head is supported and -EINVAL otherwise,
> simliar to the dmabuf vs. region probing.
> 
> It is less confusing because .head is always an input field then.
> 
> It is also a bit more flexible because different heads can support
> different modes (I don't expect drivers will actually use that though).

Should we then specify the error code for "head doesn't exist" vs "head
doesn't support dmabuf", with the former taking precedence?  Perhaps
-ENODEV vs -EINVAL.  Are the heads guaranteed to be contiguous (the
first -ENODEV is the end of possible heads)? Thanks,

Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx