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

[Ben Widawsky <benjamin.widawsky@intel.com>]

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?

-- 
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel