[Mesa-dev] [PATCH 4/4] atomic: Initialise fence FD members

Emil Velikov emil.l.velikov at gmail.com
Tue May 2 14:50:00 UTC 2017


On 2 May 2017 at 15:01, Daniel Stone <daniel at fooishbar.org> wrote:
> Hey Emil,
>
> On 2 May 2017 at 14:24, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> Seems to be the correct place to handle here, despite that both are
>> already handled.
>
> Honestly, I wouldn't have written this patch if I knew that; Lucas's
> fix came in after the last time I'd pulled, and I didn't notice since
> I didn't hit a conflict when I was rebasing. Oops.
>
>> As a follow-up can we:
>>  - drop  atomic_run's "drm.kms_in_fence_fd = -1;" + git revert
>> a46366c9903efc8b63eb4e78ae72f869be0b0a3d
>
> Dropping this in atomic_run() makes sense indeed, but honestly I think
> Lucas's fix is fine as is.
>
Yes, Lucas' commit doesn't do anything wrong. I tend to find double
initialisation a bit misleading at times, but it could be just me.

>>  - in drm_atomic_commit() use "(flags & DRM_MODE_ATOMIC_ALLOW_MODESET)
>> == 0" over "drm.kms_in_fence_fd != -1"
>
> I think this suggestion is wrong, or misleading at best. The
> first-order thing we're interested in is if there's a fence available
> to use (what the test now checks directly); the ALLOW_MODESET flag is
> just a proxy for that. I'd rather not do this. I'll send another
> related cleanup patch though.
>
Right, thanks for the correction.

My initial assumption was that having a full modeset alongside a fence
fd is not permitted.
Upon second thought no reason comes to mind why such a restriction
might be required.

-Emil


More information about the mesa-dev mailing list