On Wed, Jan 24, 2018 at 4:04 AM, Tomasz Figa <tf...@chromium.org> wrote:
> Hi Robert,
>
> On Wed, Jan 17, 2018 at 2:36 AM, Robert Foss <robert.f...@collabora.com>
> wrote:
>> This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
>> since at least 4 implementations exist, and share a lot of contents.
>> The idea is to keep the common stuff defined in one place, and libdrm
>> is the common codebase to all of these platforms.
>>
>>
>> Additionally, having this struct defined in libdrm will make it
>> easier for mesa and gralloc implementations to communicate.
>>
>> Robert Foss (7):
>> android: Move gralloc handle struct to libdrm
>> android: Add version variable to gralloc_handle_t
>> android: Mark gralloc_handle_t magic variable as const
>> android: Remove member name from gralloc_handle_t
>> android: Change gralloc_handle_t format from Android format to fourcc
>> android: Change gralloc_handle_t members to be fixed width
>> android: Add accessor functions for gralloc_handle_t variables
>
> Again, thanks for working on this.
>
> I looked through the series and it seems to be much different from
> what I imagined when writing my previous reply. I must have
> misunderstood your proposal back then.
>
> Generally, current series doesn't solve Chromium OS main concern of
> locking down the handle struct. Even though accessors are added, they
> are implemented in libdrm and refer to the exact handle layout as per
> the handle struct defined by libdrm.
>
> What I had in my mind, would be creating a secondary struct,
> consisting only of callbacks, which would be filled in by particular
> gralloc implementation running in the system with its accessors. This
> would completely eliminate any dependencies on the handle struct
> itself from consumers of gralloc buffers.
That's a non-goal IMO. The goal is to converge towards a common
definition, but the handle is not locked down. Chromium OS or any
downstream project is free to fork libdrm and make changes, implement
the accessor API in some other place, or submit changes upstream to
the handle.
To put it another way, why do we need differing handle definitions in
the first place? We have them today because no one has cared.
Rob
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
