On Tue, Dec 5, 2017 at 11:01 AM, Robert Foss <robert.f...@collabora.com> wrote: > On Tue, 2017-12-05 at 18:22 +0900, Tomasz Figa wrote: >> On Sat, Dec 2, 2017 at 4:43 AM, Rob Herring <r...@kernel.org> wrote: >> > On Fri, Dec 1, 2017 at 8:44 AM, Tomasz Figa <tf...@chromium.org> >> > wrote: >> > > On Fri, Dec 1, 2017 at 11:20 PM, Rob Herring <r...@kernel.org> >> > > wrote: >> > > > On Fri, Dec 1, 2017 at 7:30 AM, Robert Foss <robert.foss@collab >> > > > ora.com> wrote: >> > > > > On Thu, 2017-11-30 at 11:14 -0600, Rob Herring wrote: >> > > > > > On Thu, Nov 30, 2017 at 12:11 AM, Tapani Pälli <tapani.pall >> > > > > > i...@intel.co >> > > > > > m> wrote: >> > > > > > > >> > > > > > > >> > > > > > > On 11/30/2017 06:13 AM, Tomasz Figa wrote: >> > > > > > > > >> > > > > > > > On Thu, Nov 30, 2017 at 3:43 AM, Robert Foss <robert.fo >> > > > > > > > ss@collabo >> > > > > > > > ra.com> >> > > > > > > > wrote: >> > >> > [...]
>> > > However I fully agree that there are other upstream components >> > > (e.g. >> > > drm_hwcomposer), which would benefit from it and nobody wants to >> > > include Mesa in the build just for one header. Should we have a >> > > separate freedesktop project for it? >> > >> > I'm still going to say libdrm. If that's really a problem, then we >> > can >> > split it out later. >> >> At least for Chromium OS, libdrm would work fine indeed. > > Excellent, so with the question of where (libdrm) covered, that leaves > us with what. > > Currently this is what what the XXX_handle structs look like: > gbm_gralloc: https://github.com/robherring/gbm_gralloc/blob/master/gral > loc_drm_handle.h#L36 > > minigbm: https://chromium.googlesource.com/chromiumos/platform/minigbm/ > +/master/cros_gralloc/cros_gralloc_handle.h#20 > > intel-minigbm: https://github.com/intel/minigbm/blob/master/cros_grallo > c/cros_gralloc_handle.h#L20 > > A lot seems to be shared between the 3, gbm_gralloc seems to have > modifier support, but lack multi-planar YUV support. > > DRV_MAX_PLANES sounds to be a bit of a misnomer, as (I think) it refers > to YUV planes and not planes supported by the driver/hw. > > I would assume that all shared variables would be available in the > libdrm-struct, as well the ones planar YUV support. > > As for the non-obvious ones, maybe the should be listed so that we can > dig into if they are really needed, implementation specific or unused. My plan is similar to what I was thinking in the move to hwc. Move the struct as is to libdrm and get the dependencies (gbm_gralloc, drm_gralloc?, drm_hwc, mesa) switched over to use it. Then start modifying the struct contents. Here's my list: - versioning of the handle - remove .name (GEM handles. only dmabuf support) - better way to do buffer registration tracking (than a pid and ptr)? - multi-planar - switch format to fourcc (or add the fourcc format) - switch to accessor functions or library calls Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
