On 16 March 2017 at 10:48, Daniel Stone <dan...@fooishbar.org> wrote: > Hey Emil, > > On 13 March 2017 at 18:03, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 10 March 2017 at 15:12, Daniel Stone <dan...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
