[Intel-gfx] Getting primary plane_id in i-g-t
Jindal, Sonika
sonika.jindal at intel.com
Fri Jun 13 02:41:09 CEST 2014
Thanks for the response Matt.
Please find my responses inline.
Regards,
Sonika
On 6/12/2014 8:08 PM, Matt Roper wrote:
> Hi Sonika and Sagar. Responses inline below.
>
> On Thu, Jun 12, 2014 at 04:31:12PM +0530, Sagar Arun Kamble wrote:
>> Including Ville in the thread.
>> I feel we need to update following structure to reflect plane type.
>>
>> struct drm_mode_get_plane {
>> __u32 plane_id;
>>
>> __u32 crtc_id;
>> __u32 fb_id;
>>
>> __u32 possible_crtcs;
>> __u32 gamma_size;
>>
>> __u32 count_format_types;
>> __u64 format_type_ptr;
>> };
>
> Actually, I don't think you should need to update the plane structure;
> part of the primary plane conversion was the addition of a new DRM
> "type" plane property that userspace can check to figure out what the
> type of a plane is. So if you have a plane, you can call
> drmModeObjectGetProperties()+drmModeGetProperty() to get the plane's
> properties; the value of the "type" property will be one of
>
> #define DRM_PLANE_TYPE_OVERLAY 0
> #define DRM_PLANE_TYPE_PRIMARY 1
> #define DRM_PLANE_TYPE_CURSOR 2
>
> Note that you may need libdrm from git to have these #define's at the
> moment; I'm not sure if there's been a release of libdrm since they went
> into the codebase.
>
Thanks, I was not aware of this property. I will try this.
>>
>> On Thu, 2014-06-12 at 16:20 +0530, Jindal, Sonika wrote:
>>> Hi,
>>>
>>> I am writing i-g-t for primary plane 180 degree rotation.
>>> How can we get plane_id for primary plane?
>>> Following call returns an igt_plane_t for primary plane:
>>> igt_output_get_plane(test_data->output, IGT_PLANE_PRIMARY)
>>>
>>> But this has drm_plane as null, so couldn't get plane_id.
>>>
>>> Then I tried getting planes from drmModeGetPlaneResources and
>>> drmModeGetPlane. But I am getting only sprite planes from that call.
>
> A couple things here:
>
> - Since the universal plane stuff is still considered somewhat
> experimental, you need to also enable it with a kernel command line
> parameter. If you add "drm.universal_planes=1" that will activate
> the feature. I think we'll be dropping this module parameter
> requirement soon since the feature is looking pretty solid at this
> point.
>
> - i-g-t as it exists today doesn't know about the universal plane stuff
> or try to use them. I have some patches floating around the mailing
> list awaiting review that add the necessary support. I can resend
> them if you're having trouble finding them.
>
>>>
>>> I also tried, drmSetClientCap but can't figure out which plane is primary.
>
> Right, you need to call
>
> drmSetClientCap(drm_fd, DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES, 1);
>
> before the DRM will return any non-overlay planes to userspace (this is
> required to maintain backward compatibility with old userspace that
> isn't expecting to get primary+cursor planes included in the list).
> This command comes early in your program, before you call
> drmModeGetPlaneResources(). Once you set the capability bit, the next
> time you grab the plane list, it should include the extra planes and you
> can check their properties to figure out which ones are sprites,
> cursors, and primaries.
>
I tried drmSetClientCap(fd, 2, 1), but it didn't seem to have any
effect. I put this call before igt_display_init and assumed that it will
then populate the igt_plane_t structure for primary plane with drm_plane
also. But for primary_plane, the drm_plane value still remains NULL. I
need drm_plane in igt_plane_t because to set the rotation property, I
need plane_id which is part of drm_plane structure.
I just noticed that plane_resources->planes[i] is probably the plane_id
I am looking for.
Please correct me if I am missing something.
>
>>> Is there a way to get primary plane and the plane_id for that?
>
> I'm not sure I understand what you're asking here. The primary plane /
> plane_id shouldn't be required to set the capability bit (you set that
> bit before even fetching the plane list).
>
I need it to set the rotation property. Do we have it in some other
structure as well?
>
> Matt
>
More information about the Intel-gfx
mailing list