public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: 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: Thu, 12 Jun 2014 07:38:21 -0700	[thread overview]
Message-ID: <20140612143821.GM4893@intel.com> (raw)
In-Reply-To: <1402570872.3724.38.camel@sagar-desktop>

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

  parent reply	other threads:[~2014-06-12 14:38 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 [this message]
2014-06-13  0:41     ` Jindal, Sonika

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=20140612143821.GM4893@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --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