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

[Emil Velikov]

On 16 March 2017 at 10:48, Daniel Stone <daniel at fooishbar.org> wrote:
> 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.
>
Some silly questions and their respective answers. Please don't reply.
 1 Is it "the correct thing to do" - yes.
 2 Is it a trivial one line change - yes.
 3 Is it pedantic - yes, now re-read 1)

-Emil