On Mon, May 22, 2017 at 9:16 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 20 May 2017 at 01:16, Rob Herring <r...@kernel.org> wrote:
>> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov <emil.l.veli...@gmail.com>
>> wrote:
>>> On 18 May 2017 at 23:01, Rob Herring <r...@kernel.org> wrote:
>>>> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov <emil.l.veli...@gmail.com>
>>>> wrote:
>>>>> On 18 May 2017 at 05:10, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
>>>>>> 2017-05-18 12:01 GMT+08:00 Xu, Randy <randy...@intel.com>:
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Palli, Tapani
>>>>>>>> >
>>>>>>>> > It's just applied. Isn't it?
>>>>>>>> > Yesterday without this patch
>>>>>>>> > the color format is mismatch apparently.
>>>>>>>>
>>>>>>>> Yeah we do need this. TBH I don't quite understand why but will try to
>>>>>>>> figure
>>>>>>>> it out. I remember we used to have a patch in Surfaceflinger at one
>>>>>>>> point
>>>>>>>> because visual was hardcoded there and this might be related.
>>>>>>>>
>>>>>>>> // Tapani
>>>>>>>
>>>>>>> Sorry, that's for different issue, I mix it with RGB565 blending one.
>>>>>>> This patch is required because some Android GLES test apps, like
>>>>>>> gl2_basic, need to create RGBA8888 surface.
>>>>>>
>>>>>> Indeed it is.
>>>>>>
>>>>>> As Emil pointed out, the patch was merged before
>>>>>> but reverted later since it broke desktop.
>>>>>>
>>>>>> So what's the current upstreaming plan?
>>>>>>
>>>>> No idea about a plan, but how you can fix it once and for all:
>>>>>
>>>>> Extend the loader extension(s) to have a get_caps() callback,
>>>>> analogous to __DRIimageExtension::getCapabilities.
>>>>> Then the DRI module will query [the loader] and advertise the
>>>>> RGBX/RGBA visuals when possible.
>>>>
>>>> Could we do something compile time instead to enable just for Android?
>>>> Seems like a lot of complexity when the platform needing these pixel
>>>> formats doesn't need the backwards compatibility. Or maybe there are
>>>> other things needing this interface?
>>>>
>>> Having a short/mid term ifdef ANDROID is perfectly fine.
>>>
>>> Can we address some of the existing ones before/alongside the newly added
>>> ones?
>>> Afacit the nouveau bits are no longer applicable.
>>
>> Yeah. I don't explicitly warn for KK or less, but will add that and fix
>> these.
>>
>>> While for the
>>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
>>> rework or MESA_LOADER_DRIVER_OVERRIDE.
>>
>> How does the build rework help? My only reservation with using an env
>> var is generally Android things don't rely on them and it would break
>> working systems. I'm not even completely certain I can set env vars
>> globally. It would be nice if the build system could set defaults for
>> env vars we could use.
>>
> IIRC with the rework you have the dri driver names are known as we
> reach targets/dri/Android.mk
Not really because we have things like freedreno -> msm and virgl ->
virtio_gpu, but having a variable like TARGET_DRIVERS is simple
enough.
> Thus one can reuse them to create the separate drivers
> - be that one blob + {sym,hard}links as we do in autotools/scons, or
> - completely separate drivers like i965 and other classic drivers.
Got it. Symlinks are really easy in master:
LOCAL_MODULE_SYMLINKS := $(foreach d, $(GALLIUM_TARGET_DRIVERS), $(d)_dri.so)
However, that only works in master. There is LOCAL_POST_INSTALL_CMD,
but it doesn't support multilib, so we need something like this:
LOCAL_POST_INSTALL_CMD := \
$(foreach l, lib lib64, \
mkdir -p $(TARGET_OUT_SHARED_LIBRARIES)/$(l)/$(MESA_DRI_MODULE_REL_PATH); \
$(foreach d, $(GALLIUM_TARGET_DRIVERS), ln -sf gallium_dri.so
$(TARGET_OUT)/$(l)/$(MESA_DRI_MODULE_REL_PATH)/$(d)_dri.so;) \
)
This will install broken links when we're not on a multilib build. A
bit ugly, but should be harmless.
Rob
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
