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. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel