[PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Christian König]

Am 04.04.2017 um 12:43 schrieb Daniel Stone:
> Hi,
>
> On 4 April 2017 at 11:27, Christopher James Halse Rogers
> <chris at cooperteam.net> wrote:
>> On 4 April 2017 6:31:12 pm AEST, Daniel Vetter <daniel at ffwll.ch> wrote:
>>> This seems like an awful specific special case. Why can't you do the
>>> entire dance upfront, i.e. import buffer, addfb2? None of that has any
>>> visible effect, and it will also allow you to check runtime constraints
>>> which can't be covered with this here.
>> No, because addfb2 doesn't (or, rather, didn't) actually check any runtime constraints.
>>
>> The problem only appeared when the buffer is actually *used* in a modeset - otherwise I could do a (reasonably) cheap import/addfb/render on exporter/read out on importer dance to detect it.
>>
>> To be clear - this is trying to solve the problem “how can I tell if it's safe to addfb/pageflip rather than do a GL copy to a GPU-local buffer and flip from that?”.
>>
>> If I could guarantee that I'd only ever run on 4.13-or-later kernels (I think that's when the previous patches will land?), then this would indeed be mostly unnecessary. It would save me a bunch of addfb calls that would predictably fail, but they're cheap.
> Yeah, the ABI is that AddFB2 should fail hard on something which can
> never be used as a framebuffer. The fact it didn't is a bug rather
> than a behavioural change per se ...

I agree on that, but the problem Christopher tries to solve looks a bit 
different from my perspective.

He wants to know if a driver can scan out from a foreign BO or if he 
needs to copy the content.

The problem I see with this patch is that the kernel doesn't look like 
the right place for this decision to make.

Regards,
Christian.

>
> Cheers,
> Daniel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel