On Tue, Apr 15, 2014 at 12:10 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: > so, what triggers this is that previously drm_framebuffer_remove() did > not process private planes. But now the fb shows up attached to a > plane as well, the crtc's primary plane. That shouldn're really matter - if we have the fb assigned as the primary plane then the set_config_internal should clear crtc->primary->fb. Which means in the next loop (where we go over all planes) we won't look at it again. Or at least this is how it should work. So dropping a ref twice due to that would indeed be a bug, but one in drm_crtc.c. I have to admit that I don't see it really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
