Summary: When we are told to resize the canvas, we should also be
resizing the gbm_surface. This should fix the issue of wl_drm module
in E not working when the canvas gets resized (WFM now)
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: If we go to setup a tty and it is already in graphics mode,
then there is no need to exit with a failed setup here. Instead, we
can actually continue to setup the tty.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Typos, lack of NULL check, excessive sizeof(type) not matching
the object type, no border set, etc... This all lead to a crash
and then no render (with an error message and then without...).
This also simplifies the implicit loading of ETC1 as ETC2 when
supported by the driver.
@fix
This reverts commit d1f863b272.
My test script was wrong, thus the test for this commit being a pass while it shouldn’t.
Moral: don’t code when you crave some sleep.
i found that intel drm device gives BROKEN timestamps vs system clock
- it is off by about 0.3 to 0.4ms - this means the vsync event is in
the future vs when we actually wake up and do processing - this leads
to bizare timelines and likely odd event and animation handling.
fix this by detecting it and figuring out an average delay and
offsetting events by that in future, but until then, use "now" when
the drm thread wakes up as the timestamp.
@fix
This reverts commit 22b45f220c.
eina_file_cleanup always does an eina_tmpstr_del. This is now capable of doing
double or even triple free in some case.
During a rework this bit got missed and made the build fail if ivi-shell was
enabled. Thanks a lot to aerodynamik for bringing this to our attention and
even pointed out the fix.
Fixes T2798
with eo id indirection on, a nul object is silently ignored as anok
error case (like free(NULL)). but if you turne eoid off in build its
all complaints to here and the black stump. fix this by making the eo
id "off" path match eo id on by making null objects silent.
@fix
so the evas thread renderer didnt START rendering until evas FINISHEd
walking all objects generating a render queue. this means all the cpu
time spend generating commands couldn't allow a parallel thread
actually go and DO the rendering.
this flushes the render thread every render command thus waking up the
render thread to work in parallel to the mainloop generating commands.
this actually means int he traces i see the render thread finished byt
he time evas_render completes thus brinign forward the frame display
by quite a bit.
thanks to evlog for pointing this out.
@fix
removing the klass member meant removing hooks and keeping cache small
but that meant not using it. this meand if the object is not an obj...
i removed the:
call->obj = _eo_class_id_get(call->klass);
line - seemed harmless/pointless. apparently not. so put it back but
use the klass there in local vars and not in call as it's not there
(and not needed).
fix.
in the case of operations which change framespace, rejecting resizes
at this point will cause the canvas to fail at resizing and result in a
partially-rendered canvas; the real canvas geometry must be calculated by
running the entire function in order to determine whether the resize is valid
fixes toggling borderless state of windows
Summary:
Add code to unit test to check if Eolian correctly recognize a struct
name as a struct type when it is used in a method.
Add new method to struct.eo to create this test.
Update struct_ref.c accordingly.
Reviewers: tasn, q66
Differential Revision: https://phab.enlightenment.org/D3213
Chris Michael
Amitesh Singh
Jean-Philippe Andre
Shinwoo Kim
Chidambar Zinnoury
Carsten Haitzler
Cedric BAIL
Vincent Torri
Mike Blumenkrantz
Stefan Schmidt
Srivardhan Hebbar
Vivek Ellur
Jihoon Kim
Jaehwan Kim
Vitor Sousa