On Thu, 10 Jan 2019 15:20:14 -0500 Conrad Knight <iestynap...@gmail.com> said:
> On Thu, Jan 10, 2019 at 1:39 PM Carsten Haitzler <ras...@rasterman.com> wrote: > > As usual - wayland stuff is kind of new and experimental so I'd advise using > > git master for that. > > as for how to compile - look at the aur git pkgs: > > Ok, i'll give it a shot :) Couple of quick questions: > > For EFL, are "--enable-egl" and "--enable-gl-drm" not needed, then? > What configure option does "-Dbuffer=true" correspond to? > Does "-Dopengl=es-egl" mean "--with-opengl=es"? Because i don't see > any other options besides "full" or "none". that's the meson based build - you can just use it as-is and copy & paste... :) > I have to admit, i'm a little lost on the differences and requirements > for opengl, gl-drm, egl, es-egl, etc. Is there by any chance a short > reference to all these terms? once upon a time there was opengl. it included glue to the display system called glx. then it needed to work on something other than x11, so the glx functions were replaced by wgl or agl functions on windows and mac (i never looked at or touched them but i know that they exist somewhere). then the embedded world appeared with gpus on small devices and the whole opengl api was a bit too fat. it was trimmed down to opengl-es. at the same time a unified egl api was added to a separate egl library this was now "cross platform" and could be used regardless of target display system. once upon a time linux had no opengl acceleration infrastructure at the kernel level. drm was born (direct rendering manager) as the kernel interface. it also came together with dri (direct rendering infrastructure) so often the naming was interchanged. there was now a libdrm library that acted as a front-end to opening /dev/dri/card0,1,2, etc. and doing ioctl()'s and read()ing/write()ing/mmap()ing it etc. this api also took on control of kms when it turned up (kernel mode switching) to set modes and atomically swap buffers. efl has 2 gl modes. opengl + glx, or opengl-es + egl. wayland required you use egl. while in theory you can do opengl + egl, we do not offer that as an option and we do stick to almost entirely using a subset of opengl that is common with opengl-es. these days we COULD drop opengl entirely, but many years ago desktop systems only offered opengl and embedded only offered opengl-es. today mesa offers both for all the drivers i know of and nvidia also offer both even on desktops. some embedded systems have gotten to offering opengl in addition to opengl-es. so in order to use gl efl has to switch to opengl-es mode as that then allows us to work with egl and support wayland. our drm based engines (2 of them) use libdrm to render directly to the "framebuffer" but with kms etc. drm is just software based where the cpu renders to buffers and we flip buffers. some drm implementations actually can only offer basic framebuffer management like this and no gpu support. this also then works if you have a fully accelerated opengl-es stack or not. the gl_drm is what it says on the lid - uses gl with drm to have gpu based acceleration. only opengl-es though. you did want an explanation... :) > Thanks, > -Conrad. > > -- > Shine like thunder > Cry like rain > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
