[meta-freescale] mesa-dri vs amd-gpu-x11-bin-mx51

[Andrei Gherzan]

ERATA :)

On Sun, Jan 13, 2013 at 2:57 AM, Andrei Gherzan <andrei at gherzan.ro> wrote:

> On Sat, Jan 12, 2013 at 8:08 PM, Otavio Salvador <otavio at ossystems.com.br>wrote:
>
>> On Sat, Jan 12, 2013 at 4:00 PM, Eric Bénard <eric at eukrea.com> wrote:
>> > Le Sat, 12 Jan 2013 15:52:46 -0200,
>> > Otavio Salvador <otavio at ossystems.com.br> a écrit :
>> >
>> >> On Sat, Jan 12, 2013 at 3:49 PM, Eric Bénard <eric at eukrea.com> wrote:
>> >> > Le Sat, 12 Jan 2013 17:54:13 +0200,
>> >> > Andrei Gherzan <andrei at gherzan.ro> a écrit :
>> >> >
>> >> >> On Sat, Jan 12, 2013 at 4:15 PM, Otavio Salvador <
>> otavio at ossystems.com.br>wrote:
>> >> >>
>> >> >> > On Sat, Jan 12, 2013 at 11:59 AM, Eric Bénard <eric at eukrea.com>
>> wrote:
>> >> >> > > Hi,
>> >> >> > >
>> >> >> > > has anyone here already seen this messages ?
>> >> >> >
>> >> >> > Yes; I started checking it but I still do not have an absolute
>> answer
>> >> >> > to how to fix it.
>> >> >> >
>> >> >> > The problem is xserver-xorg (when it has glx enabled) it depends
>> on
>> >> >> > mesa-dri. Both mesa-dri and GPU package libraries (the mx5 and mx6
>> >> >> > ones) provide same (theorical) functionality of mesa-dri,
>> libraries
>> >> >> > and (most) headers leading to those errors.
>> >> >> >
>> >> >> > I did check how Xorg is compiled in LTIB and it doesn't has glx
>> >> >> > enabled so my idea is to disable glx in Xorg and try to go this
>> route.
>> >> >> > This would allow for a clean build at cost of making xserver-xorg
>> >> >> > machine specific. Do you have any other idea?
>> >> >> >
>> >> >>
>> >> >> Why do you need glx after all? We don't have opengl for imx53 right?
>> >> >> And about the fix. Xorg with glx should  depend on virtual/libgl
>> (or gl)
>> >> >> not mesa-dri.
>> >> >>
>> >> > mesa-dri provides virtual/libgl which can explain why we find it
>> here.
>> >>
>> >> In fact mesa provides all them (GL ES2 and GL ES1 too).
>> >
>> > yes, I was in Andrei's email context here.
>> >
>> > meta-ti has the following lines in libgles-omap3.inc :
>> > PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2"
>> >
>> > RREPLACES_${PN} = "libegl libgles1 libgles2"
>> > RREPLACES_${PN}-dev = "libegl-dev libgles1-dev libgles2-dev"
>> > RREPLACES_${PN}-dbg = "libegl-dbg"
>> >
>> > note they have the RREPLACES which are not in meta-fsl-arm's recipes.
>>
>> Makes sense; but this fixes rootfs problem, not sysroot conflict. My
>> mean concern here is now it behave in concurrent build?
>>
>> Let's say:
>>
>> - xserver-xorg building (so mesa-dri installed at sysroot)
>> - qt4-x11 build start (so will install amd/vivante libraries at sysroot)
>>
>> As we don't have individual sysroot for every package in build, this
>> is something that I don't know the end result.
>>
>> So I think the right fix is to get rid of glx for mx5 and make
>> xserver-xorg glx to build with vivante libraries  for mx6.
>>
>> What do you think?
>>
>>
> I will tell you my point of view having into consideration imx6.
>
>
Obviously wrong. Fix comment:


> There are a couple of issues here:
> 1. in oecore the glx PACKAGECONFIG concludes dri flags and glx flags.
> Which, in my opinion is wrong. These should be separated.
> 2. xserver-xorg should be compiled with dri needed for vivante driver
> 3. glx for imx6 - as we have gl
>
> Fix:
> Split PACKAGECONFIG in glx and dri.
> Use PACKAGECONFIG_append_imx6qsabrelite = " glx dri ".
>
> P.S.: I can take care of patches for imx6 in on this issue.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130113/da263f95/attachment.html>