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 <robdcl...@gmail.com> wrote:
>> On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
>> <hoegsb...@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
