Hi, > > 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. The planes don't really have an id, we should rename that to plane_type, or maybe drm_plane_type (simliar to the drm_format_* fields), to avoid that confusion. plane_type is set by userspace to specify what kind of plane it asks for. > > 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. Ok, that should work to figure whenever the mdev supports a plane region or not. > 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, I need to know whenever the mdev supports dmabufs or not, at device initialization time (because dmabufs require opengl support), when VFIO_DEVICE_QUERY_GFX_PLANE doesn't work due to the guest not having the device initialized yet. Maybe we should have a error field in the ioctl struct, or we need to clearly define error codes so the kernel doesn't just throw EINVAL in all cases. Or just a VFIO_DEVICE_GFX_CAPS ioctl which returns NONE, REGION or DMABUF. cheers, Gerd _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
