> -----Original Message----- > From: Ross Burton [mailto:ross.bur...@intel.com] > Sent: Sunday, February 03, 2013 2:04 PM > To: Ian Geiser > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] OpenGL as a DISTRO_FEATURE > > On Sunday, 3 February 2013 at 17:15, Ian Geiser wrote: > > Greetings, I maintain 3 different platforms with varying degrees of > GL support. Would it make more sense to migrate the "opengl" distro > feature to MACHINE_FEATURES? This way we could compensate for the > platforms that use Mesa and the ones that use their custom > implementations? Thoughts? > > Even if there were machine features, a distro feature is still > something you'd want. > > There's been the idea of having fine-grained machine features for the > aspects of OpenGL that the hardware supports (gl, gles, egl, etc). > It's not as simple as it appears and causes a rather large number of > packages to become machine-specific. In the case of my product that is not a problem. It may have implications on the community distributions though.
> > What would you use the machine features for? Conditionally compiling > support for a particular variant of GL into packages that cannot be > detected at runtime, or something else? > The case I have is 3 platforms: 1) Atom N450 2) WM 8950 3) VIA VX900 The Atom has the normal mesa-dri drivers and can use the OpenGL implementation from that. The WM has only OpenGLES drivers and no OpenGL implementation. So in that case I want to use only GLES support in the various packages that conditionally support it (in my case Qt4). The last platform the VIA has its own OpenGL implementation that can completely replace mesa for packages that support OpenGL. In the case of my distro I support Qt4 but it can use OpenGLES or OpenGL. The problem comes in when I start setting preferred providers in the machine conf files. In the case of my WM, I have only gles and since the distro supports opengl, it needs a virtual/libgl and finds it with mesa. Now I can remove opengl from my distro, but the Atom and VIA support opengl, and will not have it available to Qt because it turns off. So really on reflection the real problem is that when you support two platforms in the same distro that either have opengl or opengles you get into trouble. Now one approach might be to make a distro based off of the common distro that supports either opengl or opengles but that to me sounds like I am fixing the problem in the wrong place. Now I could be missing an obvious better way. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
