Hello. On Wed, 2014-07-16 at 08:32, Chris Michael wrote: > On 07/16/2014 08:20 AM, Stefan Schmidt wrote: > >Hello. > > > >On Wed, 2014-07-16 at 08:11, Chris Michael wrote: > >>This is not Entirely correct my friend ... > >> > >>While moving to ecore_drm could be a better solution, There are Still > >>drm function calls being made inside evas_drm.c. (drmModeGetEncoder, > >>drmDropMaster, etc, etc) so I think removing the link to libdrm was a > >>bit premature here... > > > >I actually thought about this. :) > > > Ahhh ok, just wanted to be sure you realized it ;)
Always good to have another set of eyes looking over the code. :) > >As ecore-drm is depending on libdrm this is no problem as the evas drm > >engine gets the libdrm dependency through ecore-drm in this case. > > > True ... but I think if you are trying to remove libdrm stuff from evas (and > rely on ecore_drm), then we May want to expose some new functions in > Ecore_Drm to deal with these libdrm calls....IMO, there is little point in > removing libdrm (from evas) if we are still going to rely on one or two drm > function calls. Better to move those into ecore_drm and remove libdrm from > evas completely. Exactly the plan. It just got postponed while I needed to fix the breakage I did to expedite when testing the drm engine. Now that this is sorted out I will move more things over to ecore-drm and add new functions on the way when needed. regards Stefan Schmidt ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
