public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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
>

      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