On Mon, 19 Jun 2017 08:34:13 +0200
Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
> Hi,
>
> > So perhaps this becomes:
> >
> > struct vfio_device_gfx_plane_info {
> > __u64 start;
> > __u64 drm_format_mod;
> > __u32 drm_format;
> > __u32 width;
> > __u32 height;
> > __u32 stride;
> > __u32 size;
> > __u32 x_pos;
> > __u32 y_pos;
> > };
>
> Looks good.
>
> > struct vfio_device_query_gfx_plane {
> > __u32 argsz;
> > __u32 flags;
> > #define VFIO_GFX_PLANE_FLAGS_REGION_ID (1 << 0)
> > #define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1)
> > struct vfio_device_gfx_plane_info plane_info;
> > __u32 id;
> > };
>
> Hmm, plane isn't really an ID, it is a type, with type being either
> DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think the
> flage above make sense.
The intention was that ..._REGION_ID and ...PLANE_ID are describing
what the vfio_device_query_gfx_plane.id field represents, either a
region index or a plane identifier. The type of plane would be
represented within the vfio_device_gfx_plane_info struct.
> What are the nvidia plane for cursor support btw?
>
> > The flag defines the data in the id field as either referring to a
> > region (perhaps there could be multiple regions with only one active)
>
> Well, we have a "start" field in vfio_device_gfx_plane_info (maybe we
> should rename that to "offset"), which can be used to place multiple
> planes into a single, fixed region.
That seems reasonable.
> Also I think it would be useful to have some way to figure the device
> capabilities as the userspace workflow will look quite different for
> the two cases.
In the region case, VFIO_DEVICE_GET_REGION_INFO would include a device
specific region with a hopefully common identifier to identify it as a
graphics framebuffer. VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
plane as a region index.
In the dmabuf case, VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
plane as a "plane ID" and some sort of
VFIO_DEVICE_GET_GFX_PLANE(VFIO_GFX_TYPE_DMABUF) ioctl would be
necessary to get a file descriptor to that plane.
What else are you thinking we need? Thanks,
Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
