[Mesa-dev] [RFC][PATCH 4/5] Android.mk: Add option to use vendor version of mesa

John Stultz john.stultz at linaro.org
Wed Jul 25 19:52:02 UTC 2018

On Wed, Jul 25, 2018 at 5:42 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 25 July 2018 at 00:21, John Stultz <john.stultz at linaro.org> wrote:
>> From: Yong Yao <yong.yao at intel.com>
>> This is a forward port of a patch from the AOSP/master branch:
>> https://android.googlesource.com/platform/external/mesa3d/+/b1e5fad1db4c1d51c7ae3a033b100a8429ae5415%5E%21/
>> Which allows boards to provide their own custom copy of mesa.
> Thanks for sorting these out John.
> My understanding was that when a custom project repo is used one
> handles that in the device manifest. Roughly as:
>  - foo.xml -> contains vast majority of the git repos with associated tags/etc
>  - local.xml -> removes any repo/project from ^^, adds new one
> Is that no longer the case, or I simply misremember how Android does things?

So, I'm not aware of the specific history behind this patch. And I
can't speak for Google, there has been a general push via the Treble
efforts to standardize the Android system image, and to push vendors
to keep any device specific bits into their own device directory.  So
there is a strong disincentive to modify projects in AOSP and in order
to include things like devboards into AOSP, the push has been to limit
any device specific changes to only the device directory git tree.

So while one can technically still replace projects with local repos
(and this is very useful for development!), I think they do not want
folks doing this for shipping devices.

We are trying to make sure device support is pushed upstream to fdo,
and then align AOSP's mesa to that, but one could imagine a board that
doesn't have support upstream in mesa, and provides its own copy of
mesa in the device directory. This patch allows the build to override
the default mesa project with the vendor provided mesa.

One concrete example here, which unfortunately I've not had time to
work on, might be if we try to integrate the revived lima work to
support HiKey's mali utgard gpu. That would require a local mesa tree
along with the developmental kernel driver.


More information about the mesa-dev mailing list