On Wed, May 10, 2017 at 2:27 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, May 10, 2017 at 8:26 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, May 9, 2017 at 5:36 PM, Rob Clark robdclark@gmail.com wrote:
Disadvantages:
- depending on userspace architecture, layers left on screen could be considered an information leak, ie. new incoming master process has access to buffers that are still being scanned out.
I'm not sure this is much of a problem really, or at least I suspect we have bigger issues: the GETFB ioctl allows you to get at the gem bo behind any framebuffer, as long as you're the current master. There's no need for that framebuffer to be active on the screen. Not sure that's a good idea really, we might want to fix up that ioctl to only hand out the backing storage objects for currently active objects. But kinda separate issue.
hmm, it would seem unusual for incoming process to inherit any fb's *other* than what is on screen (what else would be holding a ref to keep them live?)
It did occur to me that we could keep a list of "weakly ref'd" fb's in drm_file to kill at lastclose. Not entirely sure if that is useful or not.. would need feedback from various userspaces. (I did leave room for a flags field, so we could add kill-on-close flag later.)
BR, -R
Other
Oops, hit send too early: Otherwise looks good. Well, you can forgo the kernel-doc (just leave a comment if you want to explain the difference), since in drm core only the driver interface stuff is documented with kernel-doc. At least that's what I've been doing.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch