As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
As this function is only used in 1 place and will likely never be used
outside of the modular dmabuf engine, we can move it to be internal
only.
ref T8013
internal
These functions are not used in efl wayland clients nor are they used
in Enlightenment. As such, there is no reason that they need to be
public API so this commit moves them to be Internal and updates
Ecore_Evas engine code to include the internal header.
ref T8013
Summary:
When the ecore_wl2_shutdown() calling without ecore_wl2_init().
It makes crash.
Reviewers: eagleeye, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9452
so even if shm was an allowed mode/flag, we never fell back to shm if
dmabufs were not possible (/dev/dri/renderD128 didn't exist or wansn't
open-able). that's decidedly a bad thing to do.
@fix
Summary:
if wl2_input logic gets a 'touch down' event from touch device,
input->focus.touch has set and it cause the logic handles every input as touch input
from that moment at _ecore_wl2_input_mouse_move_send function.
that is the reason why the patch(410c1f9587) has written for.
however, if there are multiple touch input devices,
clearing focus.touch variable without checking any conditions causes another problem.
I mean a case such as 'touch 1 down' -> 'touch 2 down' -> 'touch 1 up' -> 'touch 2 up'
at the moment 'touch 1 up' event executed, focus.touch would be cleared,
and 'touch 2 up' and following touch events will not be executed properly at the moment.
this patch counts a number of touch devices which are grabbing to clear focus.touch at proper time.
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8787
Summary:
if there are multiple input devices, especially touch and mouse type devices simultaneous.
a logic can't recognize the current input device in _ecore_wl2_input_mouse_move_send function.
because focus.touch would not be cleared even touch actions from user has finished.
This patch clears input->focus.touch if users release their finger from touch device.
Reviewers: raster, eagleeye, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8673
again pointless:
strcpy(dest, x); -> len - strlen(x); strncpy(dest, x, len);
code put in causing new warnings. this kind of "get rid of strcpy" is
actua;;y dangerous as it's more likely a mistake is made along the way
and bugs are added. strcpy's should be reviewed and if ok - left
as-is. doing otherwise makes the code worse, not better and raises
risk. it now also produces warnings at compile time which creates
noise we just shouldnt' have.
By using the prepare read code properly we can do wayland dispatch of
multiple queues in multiple threads. I'm not advocating we ever do so,
but if a library (perhaps a gl implementation) wants to dispatch its own
queue, and that happens in a separate thread from our event loop, we
probably don't want the world to explode.
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7915
Summary: this patch replaces a volnerable function with a safer one.
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7920
Summary:
By using the prepare read code properly we can do wayland dispatch of
multiple queues in multiple threads. I'm not advocating we ever do so,
but if a library (perhaps a gl implementation) wants to dispatch its own
queue, and that happens in a separate thread from our event loop, we
probably don't want the world to explode.
Depends on D7914
Reviewers: zmike, devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7915
Summary:
gettimeofday function returns a accumulated timestamp since around 1970 by the way,
a argument from server looks like a system uptime based timestamp
in some distribution such as tizen.
so that this patch appends a logic that updates a timestamp
inside Ecore_Wl2_Input* whenever possible to
prevent gettimeofday function from being called.
Reviewers: #reviewers, cedric, devilhorns
Reviewed By: #reviewers, devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7766
They're only ever on a single list, and never counted. inlist makes
more sense.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7610
the ecore wl2.pc wanted to -lwayland_protocol ... which is never
installed. it's an in-tree .a we stattically link in, so remove it
from the pub libs in the pc. rthis was causing things that build
against efl to fail (like enlightenment).
Anchors are in window geometry, so we should be using 0,0 instead
of the parent x,y for the top left corner of the window.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7436
I'm going to deal with some ugly geometry problems in the getter func
shortly.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7431
Wayland shells have no way to unset iconified state. What this code
did was corrupt current window state in potentially fatal ways.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7430
Summary:
This prevent double destruction of source. if _ecore_wl2_input_del is called
with destroyed source, it can make unexpected troubles.
Reviewers: Hermet, id213sin, devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7265
Summary:
there is a memory leaking in some case.
this patch fixes it.
Signed-off-by: Wonki Kim <wonki_.kim@samsung.com>
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7167
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Summary: the module was not loaded when we were running intree.
Reviewers: ManMower, devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7023
It is now similar to how other modules are handled.
Differential Revision: https://phab.enlightenment.org/D7016
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Summary: the key structure has two fields key and keyname, those should be identical to the keystructures from x. the method xkb_keysym_to_utf8 however returns different values for keys like "minus" thus only relying on xkb_keysym_name files this issue.
Reviewers: eagleeye, devilhorns
Reviewed By: eagleeye
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6520
Summary:
This is now totally trivial and needs not exist.
Depends on D6522
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6523
Summary:
There's no benefit to generating ids instead of just using the
Ecore_Wl2_Window pointer in events.
This has the added benefit of working around a really nasty hash collision
bug when multiple ecore_evas engines are used at once.
ref T7053
ref T6222
@beta_break
Depends on D6521
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7053, T6222
Differential Revision: https://phab.enlightenment.org/D6522
Summary:
Turns out these can fail with EINTR or EAGAIN, and we're supposed
to try again.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6250
Summary:
This fixes a session recovery bug with software render.
An attempt to re-use a buffer in a new wayland connection resulted
in another disconnect and broken rendering.
Depends on D6281
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6282
Summary:
It's convenient to be able to pass this through this api too.
@betabreak
Depends on D6280
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6281
Summary:
We need to be able to forcibly destroy all surface buffers to make
session recovery work safely for software rendering.
@betabreak
Depends on D6278
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6279
Summary:
Since this can't be done, it probably doesn't need API.
@betabreak
Depends on D6276
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6277
Summary:
The ioctls weren't properly used so no locking took place at all, leading
to rendering anomalies when placing dmabuf buffers in hardware planes.
Also, forgetting to check error returns left no indication that the
ioctl was failing, so we now emit a warning if the ioctl fails.
Reviewers: zmike
Reviewed By: zmike
Subscribers: devilhorns, cedric, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6237
Summary:
Our wayland mouse cursor code can trigger commits with commit pending
when mousing into a window across CSD, which results in quickly setting
the default cursors then an animated resize cursor before the first commit
has finished.
Fixing this is non trivial, and the bug is just a harmless inefficiency
of little impact, so just disable the ERR for that specific case instead.
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6184
Summary:
We now have the ability to provide the seat information properly, so
fire off an ERR if a caller doesn't.
Depends on D6131
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6132
Summary:
Make it harder to misuse this function in the future.
Depends on D6129
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6130
Summary:
When a CSD button interaction under wayland leads to a compositor action
like move or resize, we essentially "give back" that button press to the
compositor, and it never sends us a mouse up for it.
We need to internally fire a mouse up event to fix up state so the client
doesn't think the mouse is still down. Until now we've been doing this
by setting a flag when we start a move/resize and checking it at next
pointer enter for the window.
This leads to unsolvable races and wacky bookkeeping, and runs afoul of
the fact that we're not actually guaranteed a pointer enter immediately
after a move completes. There is absolutely no way at all on wayland to
know if a move or resize operation has completed.
So, let's just fire the mouse up immediately on start of interaction,
which is raceless.
This fixes a years old bug where dragging a window might leave a stuck
mouse up, and allow hilighting text without drag after the window drag
completes. (elementary-test -to "text editor" with multiple windows open
exhibits this bug)
Depends on D6127
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6128
Summary:
These should never be called, so they shouldn't be API.
This kind of internal state fiddling should happen implicitly in the
API that need it.
@beta_break
Depends on D6126
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6127
Summary:
This is only fired to trigger a cursor set under wayland, but that cursor
set should be done unconditionally on mouse in.
However, mouse in was being discarded because mouse out was being deferred
when the window was "grabbed" for moving.
If instead we just let the mouse out occur as it should, the cursor
is properly updated on mouse in.
Depends on D6118
Reviewers: zmike, cedric
Reviewed By: zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6119
Clean up various places where we do flushes that we don't need to
because some immediately following action is going to cause a flush.
Also fix places where we flush without actually doing anything.
False commit when a commit is already pending is an error, but for safety
it should be a nop.
Currently it would overwrite the existing frame callback which could
cause problems on window destruction.
We should be using dmabuf sync ioctls instead of mmap/munmap every draw,
this makes that happen. The surface code continues to do what its always
done, and map/unlock.
This is now done in ecore_evas where it should be. alpha_set now does
only what its name claims it does - sets whether a surface has an alpha
channel or not.
Christopher Michael
Carsten Haitzler
Woochanlee
Wonki Kim
Xavi Artigas
Derek Foreman
Derek Foreman
Yeongjong Lee
Marcel Hollerbach
Hosang Kim
Hermet Park