Re: [PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2

From: Lucas Stach <l.stach@pengutronix.de>
To: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: "Kristian H. Kristensen" <hoegsberg@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2
Date: Tue, 02 May 2017 14:48:50 +0200	[thread overview]
Message-ID: <1493729330.13947.23.camel@pengutronix.de> (raw)
In-Reply-To: <20170428183259.GA9651@intel.com>

Am Freitag, den 28.04.2017, 11:33 -0700 schrieb Ben Widawsky:
> On 17-04-28 14:11:56, Lucas Stach wrote:
> >Hi Ben,
> >
> >Am Dienstag, den 04.04.2017, 12:41 -0700 schrieb Ben Widawsky:
> >> On 17-04-04 11:07:26, Daniel Stone wrote:
> >> >Hi,
> >> >
> >> >On 1 April 2017 at 19:47, Rob Clark <robdclark@gmail.com> wrote:
> >> >> On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
> >> >> <hoegsberg@gmail.com> wrote:
> >> >>> This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning
> >> >>> information about the modifiers that will work with each format.
> >> >>
> >> >> So, just to toss out a completely different idea..
> >> >>
> >> >> What if instead of a new ioctl, we had a read-only blob property
> >> >> (which encoded the info basically the same way, plus the fourcc's)?
> >> >>
> >> >> If we do writeback via some sort of OUT_FB_ID property on plane/crtc,
> >> >> we will need the same sort of format information so userspace knows
> >> >> what output formats (and modifiers) are supported.  So re-using the
> >> >> same blob property layout (and userspace parsing) seems useful.
> >> >
> >> >I'd definitely be cool with this. It doesn't make our lives any easier
> >> >or more difficult in terms of parsing, and it also avoids a dep on new
> >> >libdrm API/ABI, which is always nice. If anyone types this up, I'll
> >> >happily port the Weston WIP.
> >> >
> >> >Cheers,
> >> >Daniel
> >>
> >> Okay. Sounds like we have consensus. I'm working on it now. I think like Rob
> >> said on IRC, a good amount of it will be reusable from GET_PLANE2. I'm a bit new
> >> to the binary blob props, so if anyone has a strong opinion on how it should
> >> look, please speak now. Otherwise, I'll just wire up something.
> >>
> >Can you tell me the status of this?
> >I'm looking at adding tiled scanout to imx-drm and just want to know if
> >it's worth to hold my breath for the reworked patch to arrive.
> >
> >Regards,
> >Lucas
> >
> 
> The agreement was to use a blob property instead of GET_PLANE2. I wrote the
> patches:
> https://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=blobifier
> 
> However, my test vehicle, kmscube has broken on i915, so I haven't yet been able
> to test and therefore I didn't send them yet. Daniel said he'd try to wire it up
> to weston next week.
> 
> I can go back and try to make it work with legacy kmscube as well, unless
> someone wants to fix kmscube/i915/i965 first?
> 
Thanks. I'll pull those in an try to get things working with imx-drm and
kmscube.

Regards,
Lucas

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel