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
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.
On the envvar side - it is meant as a workaround. It's not something
we want to set by the build.
Android-x86 already sets some at boot time, so it should be possible
to add one there.
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
