> As discussed with Jesse on irc, drm fb handling is fragile. Current rules: > - fbs are not reference counted, hence when destroying we need to disable > all crtcs (and now also planes) that use them. drm_framebuffer_cleanup > does that atm > - drivers that hold onto fbs after the kms core drops the corresponding > pointer needs to hold a ref onto the underlying backing storage (like > e.g. for pageflip on the to-be-flipped-out fb as long as it might still > be scanned out). > > We need proper refcounting for these ... But for now this patch is missing > the plane cleanup in drm_framebuffer_cleanup.
I'd rather we fixed the framebuffer kref stuff as part of doing this rather than have a poorer API because of something we have to fix anyway. It shouldn't be *that* hard to fix, at least for this kind of use case. Resize locking, fb moving etc are ugly issues, refcount shouldn't be, and the tty layer also refcounts so we can only have the fb objects themselves to worry about as we can defer fb destruction to tty close or drm last unref even for those with consoles on them. Alan
