All of lore.kernel.org
 help / color / mirror / Atom feed
* Getting primary plane_id in i-g-t
@ 2014-06-12 10:50 Jindal, Sonika
  2014-06-12 11:01 ` Sagar Arun Kamble
  0 siblings, 1 reply; 5+ messages in thread
From: Jindal, Sonika @ 2014-06-12 10:50 UTC (permalink / raw)
  To: intel-gfx; +Cc: Kamble, Sagar A, Roper

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.

I also tried, drmSetClientCap but can't figure out which plane is primary.

Is there a way to get primary plane and the plane_id for that?

Thanks,
Sonika

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Getting primary plane_id in i-g-t
  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
  0 siblings, 2 replies; 5+ messages in thread
From: Sagar Arun Kamble @ 2014-06-12 11:01 UTC (permalink / raw)
  To: Jindal, Sonika; +Cc: intel-gfx

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;
};      

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.
> 
> I also tried, drmSetClientCap but can't figure out which plane is primary.
> 
> Is there a way to get primary plane and the plane_id for that?
> 
> Thanks,
> Sonika

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Getting primary plane_id in i-g-t
  2014-06-12 11:01 ` Sagar Arun Kamble
@ 2014-06-12 12:52   ` Daniel Vetter
  2014-06-12 14:38   ` Matt Roper
  1 sibling, 0 replies; 5+ messages in thread
From: Daniel Vetter @ 2014-06-12 12:52 UTC (permalink / raw)
  To: Sagar Arun Kamble; +Cc: intel-gfx

On Thu, Jun 12, 2014 at 1:01 PM, Sagar Arun Kamble
<sagar.a.kamble@intel.com> 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;
> };

There is a plane property which tells you the plane type (i.e.
primary, normal or cursor). Also note that support for universal
planes is currently still hidden behind a module option.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Getting primary plane_id in i-g-t
  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
  1 sibling, 1 reply; 5+ messages in thread
From: Matt Roper @ 2014-06-12 14:38 UTC (permalink / raw)
  To: Sagar Arun Kamble; +Cc: intel-gfx

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.

> 
> 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.


> > 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).


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Getting primary plane_id in i-g-t
  2014-06-12 14:38   ` Matt Roper
@ 2014-06-13  0:41     ` Jindal, Sonika
  0 siblings, 0 replies; 5+ messages in thread
From: Jindal, Sonika @ 2014-06-13  0:41 UTC (permalink / raw)
  To: Matt Roper, Sagar Arun Kamble; +Cc: intel-gfx

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
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-06-13  0:41 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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.