Anything non-EGL we might query would have to be queried here, so
I'm moving the call here to protect us in the event that we need GL
extensions in the future.
I'm still a bit confused as to what string I should be passing to
evas_gl_symbols, though.
This is a hint that we want a high priority context. Since gl_drm is
likely a compositor or a full screen app, it makes sense that it try to
use this (but other engines probably shouldn't)
Based loosely on Chris Wilson's weston patch to do the same thing.
(weston commit b678befb6ed055e6c66466505d9195a3cebf8073)
As this extension appears to have been around for years, I haven't
added fallback defines for:
EGL_CONTEXT_PRIORITY_LEVEL_IMG 0x3100
EGL_CONTEXT_PRIORITY_HIGH_IMG 0x3101
Intended to simplify the upcoming commit that merges device find and
device open into a single function that returns a device.
The fd is something callers shouldn't really need to get their hands on,
right now there are still a few places where it's needed, but those will
be gone soon too.
There's actually an array of 2 in gl_x11, but it appears we only use the
first 1, except in an #if 0 block.
I gather this is legacy for some reason - it sure doesn't seem to make
any sense now, so I'm chopping off all the extra array indexes.
Note: I've not changed gl_sdl - it looks like it doesn't use the context
or surface at all and they could just be removed, but I don't build that
one here and don't want to touch it.
so i was just about to add buffer age debugging evlogs to everywhere
doing buffer age and i found... drm gl and wayland gl engines DONT
HANDLE age change like gl_x11! they dont reset to a "full render" for
that frame. well well. this explains bugs i am seeing for sure. very
very bag! i thought this was handled properly. this does lend some
credence to my thoughts about somehow having a single universal buffer
swapping/update calculating and "applying" api inside efl somewhere...
anyway - this fixes this issue for these 2 engines which is a real
necessary fix to be correct.
@fix
Some engines should using sending surface damage, until now we'd only ever
provided them with buffer damage.
The difference is that surface damage is the damage to the surface the
compositor is displaying, and the buffer damage is the damage to the
buffer the client has rendered. These are different when the client
is using multiple buffers of different ages to render into.
Anything that calls eglSwapBuffersWithDamage, wl_surface_damage() or
wl_surface_damage_buffer() should be using surface damage, and not
buffer damage.
This patch is intended to make no functional change - any flush cb that
used buffer damage before still should. Actual fixes to follow.
Apologies if I broke any engines - it's a bit of a copy and wasteland
out here.
In efforts to reduce tearing in the gl_drm engine, find and link to
the eglSetDamageRegionKHR function so we can mark damaged regions of a
surface
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This cleans up nasty compiler warnings when building the
gl_drm engine. If we do not define EGL_EGLEXT_PROTOTYPES then we end
up with implicit declaration warnings
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: The pre/post swap callbacks were forgotten when doing the
engine rewrite, so readd them
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: Previous gl_drm evas engine code did not work properly (or at
all really). This reworks/refactors the gl_drm engine code to work
again with the changes made to ecore_drm.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This fixes compile for the gl_drm engine if
--with-opengl=full is passed on the cmd line. These changes are
based on the diff provided by spotrh in the above ticket.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This commit compiles out the debug messages that were
generating compiler warnings during build. You can reenable these
messages if you uncomment GL_DRM_DBG in evas_engine.h
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
Now, evas gl-drm engine is using ecore_drm instead of its own code to handle tty.
This patch has removed obsolete tty handling codes from engine. It is almost the same as what
Stefan Schmidt did to evas drm engine.
Test Plan: N/A
Reviewers: devilhorns, cedric, raster, stefan_schmidt
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1409
Summary: This is the first step to introduce a gl-drm backend.
Test Plan: "ecore evas" create with ecore_evas_gl_drm_new(). It creates "ecore evas" with gl_drm evas backend.
@feature
Reviewers: raster, Hermet, cedric, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1187
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Elyes HAOUAS
Derek Foreman
Chris Michael
Cedric BAIL
Carsten Haitzler
Chris Michael
Jean-Philippe Andre
Jérémy Zurcher
Gwanglim Lee
Mun, Gwan-gyeong