(Rename the subject to address the topic properly) First of all, I'm glad to invite more experts to join the devel group, including Rob Herring (kernel developer), Emil Velikov (Mesa maintainer), Rob Clark (Mesa developer), and Sean Paul (main drm_hwcomposer author) I also recall we have Chia-I Wu (olv), the original drm_gralloc author in the list.
Thanks to Sean who just opened the latest drm_hwcomposer to public: https://chromium.googlesource.com/chromiumos/drm_hwcomposer Contributing instructions: https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer Quoted from Rob Herring's email: " ... my goal here is to try to unify Android DRM support and the various implementations of gralloc and hwc. It's necessary in order to get any Android specific features in DRM upstream. I'm looking at other HALs too, and trying to unify them and address any gaps in upstream kernel interfaces. I'm also looking at device configuration and how to improve that. That seems to be something that android-x86 gets right in supporting multiple platforms in a single build with run-time configuration..." Great! Let's make it. 2016-01-16 5:30 GMT+08:00 Rob Herring <[email protected]>: > On Fri, Jan 15, 2016 at 3:10 PM, Dave Airlie <[email protected]> wrote: >>> >>> well, nothing specific, but for example early on we had some confusion >>> in drm_gralloc (when adding dmabuf fd support) about who close()d the >>> fd's. Resulting in same fd getting closed twice (although some >>> completely unrelated file handle might have snuck into that slot >>> between the two close()s). >>> >>> Or you could end up w/ the same sort of thing for gem handles (which >>> are unique to the drm device fd, so if you open() the device multiple >>> times..). I did initially have some confusion about this, w/ multiple >>> fd_bo's (or pipe_resource's) being created for a given gem handle, and >>> first one that gets deleted takes away the backing store that both >>> userspace references where using. >>> >>> You might want to look at freedreno_drm_winsys.c and the crazy things >>> it does.. I suspect virgl might need similar hacks. That is really >>> one part of two, that ensures that we share the same pipe_screen, and >>> therefore (from libdrm) fd_device, for a given drm device fd. The >>> other part is that fd_device has hashtables to deal w/ double import >>> of gem buffers. >> >> I think Rob Clark might be on the right track here. >> >> it sounds like the host is sending double deletes for some objects, which >> sounds like a possible reference counting bug in the host. >> >> So possibly something drm_gralloc, but it could be a bug in mesa, though >> I haven't triggered anything like this yet. > > Okay, I'll start digging there. > >> >> I'd be more willing to look at this if/when there is an easy to >> produce android-x86 >> image that I could just drop newer mesa/drm_gralloc into, I suppose I could >> look >> at ARM images, but I'm not really setup for cross dev, and I've a few >> other things to >> be doing. > > I've got a minimal build that is recent mesa and 4.4 kernel (only a > couple of patches on top of each) and runs in a VM (or arm64). It is > as easy as it gets with Android and rebuilding the world, but that's > not saying too much. Instructions are here[1]. > > Rob > > [1] > https://github.com/robherring/generic_device/wiki/Android-with-DRM-mesa-graphics -- Chih-Wei Android-x86 project http://www.android-x86.org _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
