I'm quite sure on Gentoo lib points to lib64 and we have a lib32
On Mon, 22 May 2017 at 22:46 Rob Herring <r...@kernel.org> wrote:
> 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
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
