On Thu, 10 Jan 2019 15:20:14 -0500 Conrad Knight said:
> On Thu, Jan 10, 2019 at 1:39 PM Carsten Haitzler 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
