From: "Jindal, Sonika" <sonika.jindal@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>,
Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: Getting primary plane_id in i-g-t
Date: Fri, 13 Jun 2014 06:11:09 +0530 [thread overview]
Message-ID: <539A48A5.50409@intel.com> (raw)
In-Reply-To: <20140612143821.GM4893@intel.com>
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
>
prev parent reply other threads:[~2014-06-13 0:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 10:50 Getting primary plane_id in i-g-t Jindal, Sonika
2014-06-12 11:01 ` Sagar Arun Kamble
2014-06-12 12:52 ` Daniel Vetter
2014-06-12 14:38 ` Matt Roper
2014-06-13 0:41 ` Jindal, Sonika [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539A48A5.50409@intel.com \
--to=sonika.jindal@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.d.roper@intel.com \
--cc=sagar.a.kamble@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox