[PATCH weston v9 06/62] compositor-drm: Refactor destroy drm_fb function

[Daniel Stone]

Hey Emil,

On 13 March 2017 at 18:03, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 10 March 2017 at 15:12, Daniel Stone <daniel at fooishbar.org> wrote:
>> Honestly, I don't think it makes any practical difference. The dumb
>> buffer itself has a reference held by the fb, so won't actually get
>> destroyed until both the buffer has been destroyed and the FB has been
>> as well. When we unmap also makes no difference, since we're not
>> touching the memory anymore.
>
> Considering the "fun" experiences Maarten had in the area (admittedly
> due to different assumptions by userspace) might be better to be
> pedantic... It shouldn't hurt weston too much.
> Although yes, my suggestion is quite paranoid ;-)

Ha yes: Maarten's joy was due to the semantics of RmFB vs.
(effectively) SetCrtc. Specifically, when the RmFB ioctl is called, if
that framebuffer is currently active on any CRTC, that CRTC _must_ be
disabled by the time RmFB returns.

On the other hand, this is RmFB vs. DUMB_DESTROY. The framebuffer
keeps a reference to the dumb buffer: the framebuffer is destroyed
immediately upon RmFB, but the dumb buffer is only destroyed when
_both_ RmFB and DUMB_DESTROY have been called, and it is only
destroyed at the last call. So I'm not concerned about changing the
order here, as that's an ABI guarantee which will never change and
isn't under threat from any of the atomic work.

Cheers,
Daniel