Since we don't actually set the color depth at all we can end up with
an RGB565 buffer. We don't ask for depths because apparently the N900
had a problem with this under X.
I'm not aware of any efforts to bring wayland to the N900, so let's do
this normally.
Summary:
"plane" exception value is already filtered at line 1791.
execution cannot reach this statement.
Reviewers: cedric, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5973
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Summary: disp is written twice with the same value.
Test Plan: N/A
Reviewers: woohyun, kimcinoo, cedric
Reviewed By: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5874
Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
strstr() can give false positives if the extension name is a subset of
a string in the extension list, for example EGL_EXT_image_dma_buf_import
would match EGL_EXT_image_dma_buf_import_modifiers.
I've opted for a mildly badgered copy of epoxy's test, which should be
robust in the face of subsets.
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
Summary:
Increasing offset as 2 for next map points is wrong.
If evas tries to draw for wrong combination of map points,
it can cause wrong results. Actually, every drawing code for
map points use and increase offset as 4.
@fix
Test Plan:
A test case for textpach is modified for testing this issue.
1. Run elementary_test with sync render mode.
ex) ECORE_EVAS_FORCE_SYNC_RENDER=1 elementary_test
2. Open textpath test.
3. Set a short text by clicking newly added check box.
4. (It will show another issues... So,) change slice number to update textpath properly.
5. See some noises at top-left side of text.
It is drawn from the two of end map points to the two of empty(not used) map points.
Reviewers: raster, cedric, jpeg, jypark
Differential Revision: https://phab.enlightenment.org/D5833
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
We already include the Ecore_Drm2 header for these engines, so there
is no need for the 'output' field to be a void pointer here.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
The dirty bit was a dirty hack to let session recovery force reconfigures
on startup.
Now that we have a surface flush we can achieve the same thing by just
discarding all buffers immediately.
For SW engine we need to verify that OSMesa is present. The patch
fb048e7312 broke the logic.
Tested by temporarily removing OSMesa from my system.
Fixes T6617 (again)
osmesa needs llvm. llvm apparently just by dlopening or linking to the
lib (libLLVM...) gets you 3.5mb of dirty pages just in this lib. that's
a whole lib entirely dirty pages. odd and horrible. in fact once i
stoppd dlopening OSMesa all the time on engine init (and only when gl
is needed)... the amount of dirty pages went from 17208 to 8860.
that's a whopping drop of 8mb! 8mb saved! in fact just dlopening
osmesa and doing the other gl init stuff led to more anonymuse
mappings with dirty pages. 2 of them (2072k and 2076k) which baffled
me as that didn't seem like heap or efl's own data. these disappeared
along with libLLVM-5.0.so (3520k + 60k dirty pages). we stopped
linking/loading libedit (12k dirty), libglapi (20k dirty),
libLLVM-5.0 (3580k dirty), libncursesw (72k dirty),
libOSMesa.so (260k dirty), libtinfo (20k dirty). ... or at least
stopped until absolutely needed. total 17208k of dirty pages went down
to 8860.
my test case was just launching terminology (and doing nothing with it).
@fix memory bloating
Summary:
The default backend overrides this operation depending on the fill color
but the cairo backend dosen't hence cairo will always use bled mode while drwaing the vector.
Reviewers: jpeg
Subscribers: vtorri, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5724
This is very useful to specify precisely which kind of RGBA -> Alpha
conversion you want. If all you wanted was the alpha layer to use as a
mask, set this flag to true.
@feature
Summary:
The Encoding key is no longer required, all desktop files are assumed to
be UTF-8 encoded. See details at:
https://standards.freedesktop.org/desktop-entry-spec/1.1/apc.html
Fix various typos and misspellings
lintian, Debian's package checker, uses strings to check for common typos
in compiled binaries. This change fixes the ones it identified in 1.20.6.
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5584
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This small patch just checks that we have a valid surface and bo that
we can pass to gbm_surface_release_buffer. If they are not valid, this
causes a hard crash.
NB: This does not actually Fix the ticket issue....
ref T6483
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If we want to share a gl context (we do) between multiple instances of
gl_drm, we need to make sure they all use the same gbm_device.
This resolves a blocker for multi-output on the gl_drm backend.
Multi-head is hitting corner cases where there are lots of locked buffers
and it looks like right now 5 is the magic number that makes the problem
go away.
Make it possible to set 5 or more (via env var) for testing, make a macro
for MAX_BUFFERS instead of just a number.
We no longer allocate 3 buffers at startup, we now allocate only as needed.
Trimming the queue will come later, as there are some situations where we
might need 3 buffers and later drop down to 2 (when on a hardware plane)
Most clients will only ever need 2 buffers, so this is a reasonable RAM
savings.
It does us no good to be able to allocate dmabuf capable memory if the
compositor can't handle it. This should fix failures on systems where
allocation is possible but the compositor doesn't advertise dmabuf.
This moves all the platform specific buffer allocation into ecore_wl2
instead of the engine.
Note that this makes an internal struct available in the header. This
will be removed shortly.
Currently the buffer code looks up the alpha stats from the surface code.
This won't be possible when we move the buffer code into a library, so
prepare for it now.
The new library function provides the same functionality and will allow
us to stop tracking things in the engine that the library already knows
about windows (compositor_version)
The dmabuf code has been creating ARGB buffers all the time. The old
wl_shm code correctly respected the alpha field, but that was lost in
the new version.
I'm not sure we ever create non-alpha wayland buffers, since CSD has
to have alpha to do shadows, but if there's any way to do it it'll
work now.
This is what the old shm code has been doing, and it's probably better
than what the dmabuf code was doing.
We currently allocate 3 buffers. The usual case has us swapping between
two of those buffers and saving that third buffer for emergencies - if
we ever need that third buffer it'll require a full redraw.
If we return the oldest available buffer the usual case requires a little
more damage but we should never hit the full redraw case, which can cause
a frame drop on slow hardware.
Now that we're dependent on create_immed there's no possibility of falling
back to non dmabuf allocation.
The only failing case we really need to handle is failing the first
allocation, which is currently broken and I'll be adding an advance test
for it shortly.
wl_shm and dmabuf only really need to differ in how they allocate a buffer,
but right now we've got them in separate files. This dramatically
reduces the complexity of the wl_shm code and shares much more
implementation with the dmabuf code.
This throws away at least one "optimization" wl_shm used - over-allocating
buffers so that window resizing doesn't always require a new buffer
allocation. If people feel that window resizing has become too slow now
this can be added to the dmabuf code to the benefit of both allocators.
Disabling dmabuf by env var still uses the old wl_shm implementation for
now, but soon that code will be removed entirely and the env var disable
will use this path.
Summary:
Refactoring.
It is good to store values from that struct in a parsing/loading context
static variable is a big NO NO:
1. Ugly code design,
2. Might not work when trying to load more than one SVG file.
@fix
Reviewers: jpeg, smohanty
Subscribers: jenkins, cedric
Differential Revision: https://phab.enlightenment.org/D5399
Accodring to https://www.w3.org/TR/SVG/types.html#Length
length ::= number ("em" | "ex" | "px" | "in" | "cm" | "mm" | "pt" | "pc" | "%")
This is still work in progress since some of lengths should be treated
differently, for example gradient lengths
Just as a starter to make a working background that, later on, will go
through Svg_Node's and build a certain source code to be saved in SVG
picture as a file
Coverity reports that _evas_dmabuf_buffer_init function here can
potentially free the surface that was passed into it. If that happens,
we should not be calling the _fallback function with surface as the
parameter as that will directly dereference the freed pointer.
Fixes Coverity CID1381707
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
In most engines which inherit from software_generic, they do not
implement the outbuf_free_region_for_update function. Most engines
have it as an unused function. If we simply add a check here, then we
can reduce the need for having useless function in multiple engines.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If the image has no data, it may get an allocated surface of 1x1 but it
is not sane to return the pointer to that data, as the user would expect
a normally sized image (in my case, 1920x1080).
I do not fully understand what is going on with this image. But at least
this transforms a crash into a simple ERR in ~/.xessions-errors
Two similar crashes happened:
- SIGSEGV by writing data outside of the image data
- abort() in free() because the malloc metadata has been overridden
when writing outside of the image data (newly allocated 1x1).
Fixes T5957
@fix
this is normal - brute force trying loaders until one succeeds is
normal is etn doesnt help identify it or it fails the first
guess-by-extension. printing errors is not good as this is an ok and
EXPECTED error. slience!
@fix
We've really always needed to do immediate creates. On a surface resize
there's no place to wait for the round trip for the new buffers to exist.
We've gotten away with this until now by good luck because we dispatch
wayland events during asynchronous render. However, with async render off
or if schedule happens in an unfortunate order, we can end up with
tearing.
Outbuf shouldn't have to track its hidden status, that should be ecore_evas
problem. Until now we were doing this because our kludgey wayland
ticking made things difficult, but I think it's safe to remove now.
Coverity reports passing a null pointer 'im->gc' to
evas_gl_common_context_flush which directly dereferences it, so lets
be sure that 'im->gc' is valid before passing it to context_flush
Fixes CID1374273
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Coverity reports that there may be a null pointer dereference here so
check that 'error' exists before trying to set it.
Fixes CID1374272
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
Small patch to fix Coverity reported issues of uninitialized variables
Fixes CID1381306, CID1381305, CID1381304, CID1381303
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch adds support for software rotation in the evas drm engine.
This is a fallback codepath in case hardware rotation is not supported
for a given rotation amount. This patch also fixes a leak of and
pending updates during output buffer free.
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This patch provides an override in the evas drm engine for the output
resize function. We override this function so that we can reconfigure
the output buffer.
ref T5999
Signed-off-by: Chris Michael <cp.michael@samsung.com>
enlightenment internal windows insta segv e on rpi. after much hunting
it seems a fallback is happening and bunk ptrs are being used. this at
least will make the problems more reliable with null ptrs.
Turns out the "device_open" function pretty much just tests calloc
functionality, and doesn't open any device. So let's allocate a
tiny bo and discard it to make sure we're actually on exynos.
Summary:
Function argument was renamed, but in function body still uses old
variable name.
Test Plan: Build on Windows host
Reviewers: cedric, vtorri
Reviewed By: vtorri
Subscribers: jpeg
Tags: #windows, #efl
Differential Revision: https://phab.enlightenment.org/D5152
We had a hack in place to flush the display from an idle enterer instead
of after a surface commit. This led to a problem where the idle
enterer dispatch order was:
renderer for main canvas
wayland dispatch idle enterer
renderer for mouse cursor canvas
The surface commit for the mouse cursor was never dispatched, so the mouse
cursor animation would only update at the rate other events occurred.
By flushing at the appropriate times instead we ensure a proper update.
ref T5850
gl_generic_context_find() returns the gl shared context struct but
this is not just a read-only operation. It in turn calls window_use
which may call make_current. This can invalidate the work of evas gl
when the API tried to switch to a specific context.
This fixes evas gl with multiple outputs.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This backend has received no patch and maintenance from anyone who could
actually test it over the last few years. After talking with KaKaRoTo it
is best to remove it. If anyone want to take over its maintenance, you
are welcome to revert this patch.
Derek Foreman
Bowon Ryu
Daniel Kolesa
junsu choi
WooHyun Jung
Cedric BAIL
Youngbok Shin
Chris Michael
subhransu mohanty
Vincent Torri
Jean-Philippe Andre
Carsten Haitzler
Marcel Hollerbach
Ross Vandegrift
Pawel Aksiutowicz
Vitalii Vorobiov
Prince Kumar Dubey
Mykyta Biliavskyi