Yes it works now!

Bug still present with efl-git-1.22.99.62458

Good news, this bug seems solved with efl-git 1.22.99.62358 and enlightenment-git 0.23.0.23575

Same issue with X environnement

Until you solve this problem, e works better with this variable. Thanks.

New valgrind -massif file today, 13 hours running enlightenment.
kernel linux-lts 4.14.71-1
efl-git 1.21.99.59809
enlightenment-git 0.22.99.23417
https://pastebin.com/uVmA2j8C

It should work
massif file name: 'massif.out.20204'
https://pastebin.com/Y2XsRujj

I apologize for this huge file. Public pastebin doesn't work for me...

Maybe useful:
original massive file is massif.out.20204

My apologize, paste access is public, now...

Here is valgrind -massif log. Running enlightenment about 9 hours.
efl-git 1.21.99.59807.ge9e63f3c0d-1
enlightenment-git 0.22.99.23417.ga03700103
https://pastebin.com/C8gq4Khv

It seems this annoying bug doesn't come from enlightenment but from wayland. I tested Firefox in a weston session, it's worst!

Bug is still there with efl-git 1.21.0alpha1.59380.g655c5ee6e0-1 (Linux Arch Aur).
It disappears if I restart enlightenment then it reappears after half or one hour.

I get nearly same bugs with last efl-git 1.20.99.58032 and enlightenment-git 0.22.99.23369

• When I try to click and scroll menu, it disappears or/and flickers with login menus.
• When I launch wayland session I get error message 'cannot initialize Ecore_X!''

Apps concerned: firefox, digikam, avidemux-qt, thunderbird, gimp, etc...

Other problem with Gimp: mouse cursor disappears

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks both a project and an assignee. If this ticket is not spam, please reopen it after adding these items.

Thanks. Sorry for the noise...

Arch Aur
https://aur.archlinux.org/packages/efl-git/
https://aur.archlinux.org/packages/enlightenment-git/
wayland session
Same bug with efl-git 1.20.99.57659 and enlightenment-git 0.22.99.23329 when using Digikam I try to move/copy pictures...

I recompiled efl and e:
wayland session
Same bug with last efl-git 1.20.99.57388.g7255954ccc-1 and enlightenment-git 0.22.99.23318.g3c7f444f1-1
E crashes when using Digikam I try to move picture file from directory to another directory

vt switching is not even done by the WM. It's totally an internal matter inside the Xserver

Yes but with e22+wayland, I can switch to tty or another user wayland session. So I'm waiting for wayland to be less buggy...

Yes but only Enlightenment causes the Xserver crash...

Conditions: Arch system x86-64, self compiled enlightenment 0.21.9 with efl 20.3
This problem happens with e dialog box
settings -> settings panel

properties -> position, size, application size or name (.desktop)

For this window, 'window remember' never remember 'application size or name (.desktop)'

Open window, resize it and move it at the screen center
click on
window -> remember -> identifiers -> window name, class, title, type
-> properties -> position, size
-> apply
Close window
Re-open window
window forgot size and position
Modifications disappeared from dialog box

I report this bug as x11 bug here
https://bugzilla.redhat.com/show_bug.cgi?id=1373834

May be interesting
I got same problem with Lxde and Openbox
No problem with Xfce4, Blackbox, Icewm and Cinnamon...

Bug report is here
https://bugzilla.redhat.com/show_bug.cgi?id=1370929

I compiled efl 18 and e on a fedora 23 under virtualbox.
Software works normally. I can't use gl, it says e is not compiled with opengl but it is
with all mesa devel dependencies and '--with-opengl=full' option
May be virtualbox problem...

In T4415#67584, @raster wrote:

can you try with an older fedora and same efl? fedora24 under vmware/virtualbox/qemu? i might try under a vm if i find some time but i'm pretty busy...

In T4415#67584, @raster wrote:

eh? wtf? so...

before sw worked, and gl didn't.

Yesterday, before update, sw and gl didn't work

after update...

gl works, sw doesn't.

right?

Today, after update, gl works, sw doesn't, but I'm not sure update change something, maybe...

In T4415#67561, @raster wrote:

you were on software? wait - does the issue appear only when in gl? there is no log there.... that can't be right... wait is this in x11 or wayland mode?

Yesterday, after editing efl18 src evas_x_main.c , compiling, installing and configure e, I was on opengl and x11. It didn't work, it was frozen.
May be important: today, i updated my fedora 24 system, libevdev was updated http://koji.fedoraproject.org/koji/buildinfo?buildID=793461
I started e. It works normally, no freeze :)
Then i changed opengl conf to software: it doesn't work, freeze again.
Then I changed software conf to opengl: it works normally
For me, it seems it's software problem, not opengl.

In T4415#67524, @raster wrote:

@maderios well that backtrace says e is "waiting for stuff". timeouts, events etc. to come in... that's a normal state.

so the reason i asked about vsync is that ecore explicitly refuses to render frames faster than the animator tick. it times frame renders exactly to an animator tick. animator ticks by default come from the system clock and are timed at a framerate... 60fps for example is a default value there.

but with specific hardware we open /dev/dri/card0 and ask the gpu to give us vblank/vsync events directly timed to the screen refresh. there is whitelist of known working cards there and everyone else will fail and fall back to the above system clock. that's why i asked you to disable vsync to see if perhaps we were not getting vsync events and that was causing issues because ecore will just refuse to render an update at all until it gets an animator tick.

so that doesnt seem to be the issue... well now the debugging gets hard. the next point of call is if evas is at all doing a swapbuffers.

so first. using gl or software for e's compositor? i shall assume gl right now. is efl built for egl/gles or opengl/glx? if the first we care about EGLSwapBuffers or otherwise glXSwapBuffers.

there is no magic env var you can set to do this... so your best best is this. you will have to recompile efl. you will have to src/modules/evas/engines/gl_x11/evas_x_main.c -> open that file in an editor. the eng_outbuf_flush() function is the one you are interested in. that will call the appropriate swapbuffers command. so see the ''#ifdef'' GL_GLES - that section until ''#else'' is for egl/gles. the stuff from ''#else'' to the last ''#endif'' in that func is for glx/opengl. so if you are built for glx/opengl then add a:

static int frame = 0;
printf("SWAP %i\n", frame++);

right above glXSwapBuffers() (or if egl/gles right above glsym_eglSwapBuffersWithDamage() or eglSwapBuffers() - make the printfs different strings so you know which is happening).

now from your .xsession make enlightenment_start redirect stdout like:

enlightenment_start > ~/swaplog.txt

then see... do you get swaps with frame numbers happen while the screen isn't updating. simple: tail -f ~/swaplog.txt from a terminal in e... move mouse. do you see a whole bunch of swapbuffer prints with frame numbers appear at once after not moving mouse for a while? or does only 1 appear on the first mouse move then every move after that another line? basically i'm wondering if we're swapping buffers - which we should be, but somehow x is refusing to display them. i kind of have a hunch you have a problem over on the xserver side and i'm bisecting to see if we are trying to swap at all. if we are - then the issue lies inside your gl driver libraries or the xserver itself and whatever 2d driver it has and any options it may be given. if we are NOT swapping... then the issue lies higher up - next port of call - is evas_render() being called by ecore_evas at all? have to bisect and find where in the pipeline the issue is.

i have never seen this issue before. not on nvidia, nouveau, intel or radeon. on any of my machines. i suspect the issue stems from something that is different on your machine to any of mine... thus why i currently suspect something lower level. but let's see.

I don't know if it's useful, I produced backtrace

In T4415#67389, @raster wrote:

@maderios ... im wondering if this is a vsync event issue for you. can you set the following environment variable prior to running e:

export ECORE_NO_VSYNC=1

e.g. from your ~/xsession or ~/.xinitrc or /etc/profile just launch e manually from a tty and set that env var... however you like...

In T4415#67309, @raster wrote:

what gfx card/driver?