Re: [RFC][PATCH 2/4 v2] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 24, 2018 at 1:05 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> On Wed, Jan 24, 2018 at 7:23 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote:
>> On Tue, Jan 23, 2018 at 03:16:37PM -0800, John Stultz wrote:
>>> This allows for importing buffers allocated from the
>>> hikey and hikey960 gralloc implelementations.
>>>
>>> Cc: Marissa Wall <marissaw@xxxxxxxxxx>
>>> Cc: Sean Paul <seanpaul@xxxxxxxxxx>
>>> Cc: Dmitry Shmidt <dimitrysh@xxxxxxxxxx>
>>> Cc: Robert Foss <robert.foss@xxxxxxxxxxxxx>
>>> Cc: Matt Szczesiak <matt.szczesiak@xxxxxxx>
>>> Cc: Liviu Dudau <Liviu.Dudau@xxxxxxx>
>>> Cc: David Hanna <david.hanna11@xxxxxxxxx>
>>> Cc: Rob Herring <rob.herring@xxxxxxxxxx>
>>> Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx>
>>> ---
>>> v2:
>>> * Make platformhisi and the generic importer exclusive in the build
>>
>> I actually prefer the opposite. If everything is always compiled, we reduce the
>> chance of breaking boards when the base class is updated. I'm sure there is a
>> good reason for this, but perhaps there's another way?
>
> The main reason for this was avoiding the build breaking when
> "gralloc_priv.h" isn't supplied or present.
>
> Similarly the current freedesktop/master code won't build in the
> Android environment as the platformdrmgeneric.cpp file depends on the
> gralloc_drm_handle.h, which doesn't exist.

That will be fixed soon. We're moving the handle definition to libdrm.

The idea was to provide an accessor API to return all the data needed
and then custom gralloc handle implementations can provide different
accessor functions. This may be enough to get rid of different
importers, but you still need some magic to pull in different
implementations whether header inlines or library functions.

The intent was to not be runtime selected because there's only ever
one handle implementation and we want to encourage converging on one
handle implementation.

> Earlier to avoid this I had included Rob's "provide a common gralloc
> handle definition" patch, but build-conditionalizing the importers
> seemed like a sane solution.
>
> I'm of course open to alternatives, but I'm not sure how to add the
> hisi importer and the drmgeneric one and keep things building without
> also adding copies of the various gralloc headers to the project as
> well.

Sometimes just copying the headers is the easiest, but whomever
maintains the original needs to know that to avoid breaking people.
And you don't have control of that since this comes from ARM.

Rob
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux