Summary: This reduces the number of output events that wl_drm module
will receive from ecore-drm. We now only send those events when an
output gets enabled/disabled where previously we were also sending
them during output creation.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This greatly improves rendering speed in evas drm engine.
Previously we would always call drmModeSetCrtc regardless if it was
needed or not. These changes greatly improve rendering speed in drm as
we now only call drmModeSetCrtc if it is needed.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: These API functions should be used for enable/disable of a
given output. They were previously being misused to stop/start
rendering on an output when we VT switch away so now we add an
internal function we can call to disable/enable rendering.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
I hope this will be enough to make the suite less broken.
This fails often on jenkins and cedric's box. This should
either be made reliable, or removed, but the current state
is definitely not good if we would like to increase the trust
in Jenkins.
Summary: This fixes build for aarch64 when TILE_ROTATE is disabled and BUILD_NEON is enabled(it is enabled by default for aarch64 since https://phab.enlightenment.org/D2309).
Reviewers: cedric, raster
Subscribers: cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D2498
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
if your virtual size is fairly big AND your actual object size is also
big, you easily overflow a signed int for intermediate coordinate
calculations, resulting in seeing only a small fractin of your objects
correctly. this fixes that by expanding up to long longs internally to
allow for the added space needed for the multiplications
@fix
EGL might very well not support RGBA read mode, so we
need to check for it first.
Also remove some error logs (see previous commit), and useless
initialization of the Evas GL engine.
@fix
Summary: When we make a call to get the geometry of all outputs, we
should be skipping ones which are not connected.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This fixes an issue when searching for possible crtcs that an
output can work on. Previously, we would end up not returning any
possible crtcs due to not looping the crtcs of the resource.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This adds a new 'name' field to the Ecore_Drm_Event_Output
structure so that when we catch drm output events in E, we can compare
this name to find an e_randr screen and update compositor's outputs.
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we will use the edid string inside RandR code to store
unique information about an output, we should be returning this edid
in a "readable" form.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: When we are parsing the edid string, if the string is random
junk, then we need to ignore it. Prior to this commit, we were not
setting the returned text properly.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As input->grab_count is an unsigned int there is no need for
the < 0 comparison as that will always return false
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
The touch screen device generates touch events.
But in some special enviroments, a first finger will be matched to a pointer event(not touch event).
And other fingers (second, third, ...) will be matched touch events.
In that case ecore_wl_input_ungrab() is called abnormally.
A first finger pressed, _ecore_wl_input_cb_pointer_button() call ecore_wl_input_grab().
A second finger pressed, _ecore_wl_input_cb_touch_down() is called but not grab.
But when a second finger is released, _ecore_wl_input_cb_touch_up() call ecore_wl_input_ungrab()
So ungrab function generate two mouse up events and a first finger is released.
In other case, first finger pressed -> second finger pressed -> first finger release.
That case when a first finger released a second finger release event is generated.
So after that application doesn't get a release event about a second finger
when a second finger is really released.
I think in a multitouch case, ungrab function will be called when a all finger are released.
So I add a grab_count variable for count currently touched fingers.
And only called a ungrab funtion all fingers are released.
Test Plan:
In a touch screen supported multitouch, press two or more fingers and release.
And watch events generation.
Reviewers: raster, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2481
Summary: This adds a new API function to test if a given
Ecore_Drm_Output can be used on a given crtc. This is needed for DRM
RandR support
@feature
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Using EINA_LOG_LEVEL=4 for standard debugging has now become
absolutely horrible (and slow!). Backtraces may make sense in
case of ERR and CRI messages, but are just pollution for other
levels.
WRN could be argued over but the old env variable is still there
so just use it if you want backtraces:
$ export EINA_LOG_BACKTRACE=2
Based on a quick git diff we check that the glsl code has not changed.
This should fix out-of-tree builds and avoid all source modification
unless required.
When compiling from a tarball there should be no git tree (err 129),
or if there's one the files should not be checked in (ie. no diff).
If you changed the glsl files in a tarball... too bad for you.
If this is still not enough to fix the build, then go ahead and disable
the script from Makefile_Evas.am
I would like to note that the auto-generation during make is extremely
useful when working on the shaders, which is why I'd rather keep it enabled.
@fix
Summary: ecore_wl_dpi_get will return the correct value after wl_output's events are handled
Reviewers: zmike, devilhorns, bryceharrington
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2479
In the nightly builds we have debug enabled and this spotted the case where
rg_etc1_solution_coordinates_block_colors_get is actually still used:
lib/eet/.libs/libeet.so: undefined reference to `rg_etc1_solution_coordinates_block_colors_get'
Showed only after we switched back from release to dev mode.
@fix
Update to 6a0d23. Casting to int isn't a real solution, since we could
have values which overflows.
Since we want the absolute value, just make sure we subtract the larger
value from the smaller.
We need to build everythign else before. Without this dep running check-build
as first target from a fresh build will fail due to wrong dependency handling
(like no eolian run over the eo files, etc)
Inspired by D2489 from Kabeer Khan.
Chris Michael
Daniel Kolesa
Tom Hacohen
kumar navneet
Oleksandr Shcherbina
Yury Usishchev
Carsten Haitzler
Ji-Youn Park
Jean-Philippe Andre
Vitor Sousa
jhyuni.kang
Stefan Schmidt
Boram Park
Sebastian Dransfeld