From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jindal, Sonika" Subject: Re: Getting primary plane_id in i-g-t Date: Fri, 13 Jun 2014 06:11:09 +0530 Message-ID: <539A48A5.50409@intel.com> References: <53998612.4070504@intel.com> <1402570872.3724.38.camel@sagar-desktop> <20140612143821.GM4893@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id D8A806E400 for ; Thu, 12 Jun 2014 17:41:15 -0700 (PDT) In-Reply-To: <20140612143821.GM4893@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Matt Roper , Sagar Arun Kamble Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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 >