On Fri, Aug 8, 2014 at 12:35 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > Ewww, this is ugly. You now make the unregistration dynamic and it's > no longer under driver control. The typical device-control flow > assumes there's an authority that controls at which point objects are > registered and unregistered. You now bind it to ref-counts. To be > fair, I think lastclose is equally hackish (and doesn't really work > like you argued already). Nope, it don't bind the unregister to the refcount, I only make the registerstration weak so that you can do such games. For all the normal framebuffers and anything controlled by drivers we can still unregister at any point before the final unref. > I think the real problem is that you want two ref-counts: One > ref-count controls the object availability, the other ref-count > controls the visibility to user-space. This is also what gem does: you > have a kernel-internal ref-count for each gem-object, but you also > have user-space handles. A handle implies a kernel-internal ref-count > but not vice versa. And the object is only accessible from user-space, > as long as you own a handle. I think we want something similar for > FBs. This way you could unregister the bios-FB once no handle exists > (assuming a CRTC owns a handle as long as the FB is used as scan-out). > > But I guess no-one wants to implement this, so I still think this > patch is the nicest way to make it work. So I'm fine with it. This doesn't actually solve anything here - the problem is exactly that this fb just exists, with no one having an access handle (beyond the internal usage refcount) on it. Not the fbdev emulation, not anything from userspace. But we want userspace to get at it with a gettfb call for smooth transitions, so simply not registering it also won't work. The thing just hangs of a few crtcs and should survive as long as that's the case, but as soon as it's no longer used it should get reaped. So the right place to hook the unregistration into is really when the last refcount goes away. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
