On Fri, Apr 22, 2016 at 12:27:16AM +0000, Christopher Larson wrote: > On Thu, Apr 21, 2016 at 5:06 PM Denys Dmytriyenko <de...@denix.org> wrote: > > > All, > > > > I've been meaning to ask this for quite some time. It appears that Weston's > > DRM compositor enabled with "kms" PACKAGECONFIG doesn't really need the > > entire > > mesa, but it only needs libgbm. Now, mesa in OE-Core provides libgbm as > > one of > > its packages, hence virtual/mesa is added in DEPENDS for kms: > > > > PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm > > udev virtual/mesa mtdev" > > > > On TI platforms with SGX GPU we have GLES/EGL stack (provided by > > proprietary > > blobs, yeah) and a separate libgbm, based on Rob Clark's > > https://github.com/robclark/libgbm > > Since that is enough to run Weston on our platforms, I've been carrying > > this > > bbappend for long time: > > > > PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm > > udev libgbm mtdev" > > > > It's been working fine for long time, but people keep on asking questions > > and > > require cleaner solution, since bbappend in a separate layer is somewhat > > confusing. Now, the question is what is a proper solution here: > > > > 1. Change weston recipe in oe-core to depend on libgbm instead of > > virtual/mesa > > assuming that it is provided by mesa recipe and it works for other > > platforms. > > > > I'd say this, either libgbm or virtual/libgbm. > > 2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa, > > although > > it looks like a hack and is somewhat reverse... > > > > I think the libgbm recipe would basically be lying if you do that, that > doesn't sound ideal.
Thanks, Chris. One other thing I was thinking is how to avoid conflict between separate libgbm and the one provided by mesa-gl. As mesa-gl may be useful for providing SW rendering for OpenGL, while leaving OpenGLES to a separate provider, like SGX. Unfortunately, mesa-gl also provides libgbm - would PACKAGECONFIG to use a standalone external libgbm work and be acceptable here? -- Denys -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
