Matt Hoosier

Right; the dumb framebuffer allocates its own dmabuf, it naturally owns the lifetime of the fd. For the dmabuf framebuffer, how about we just do a dup() on the incoming...

Yeah, I quickly ran into a an exhaustion of fd's when I ran a render loop that wrapped buffers (submitted by a Wayland client) in kmsxx::DmabufFramebuffer() objects that got discarded...

Sure, I can (and do for now) track and close the FD in the enclosing code. My suggestion is that usage of the DmabufFramebuffer is harder to understand because of...

I've pretty much found that I can accomplish my use-case with ExtFramebuffer rather than using DmabufFramebuffer (the main advantage of DmabufFramebuffer is that it provides an implementation of map(), but...

Yeah, the ownership lifetimes are the same. But that's less shocking for handles because the GEM handle to a renderbuffer is by definition long-lived. Prime FD's can be manufactured on-demand...

I haven't been able to test the changes to multi-output and compositor (don't have a machine that has both enough overlays to exercise it and whose driver is new enough...