All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.