In D12291#235031, @billiob wrote:

I've done some changes to make it still work on some distro I use. Could you please test latest branch?

I've done some changes to make it still work on some distro I use. Could you please test latest branch?

Remove unnecessary change

Remove unnecessary changes

Already fixed in git. Will be in v1.7.4.

Thank you, that makes things much simpler on our end!

This problem was just fixed in git (yesterday). It was a regression since 1.6.x.
Imlib2 uses the file name extension only as a first guess. After that it tries all loaders.
All loaders do signature checks like you describe.
Thanks for reporting :)

Ah, maybe I can run it through valgrind later, will see.

The top crashdump is the same place. It's deep inside the nvidia driver somewhere and no idea why. this certainly is not the notification bug thing you saw (I've been trying to reproduce it with asan on and find nothing here - e keeps running solidly day after day with notifications and i installed the same browser extension you did). but .. this is on amd - different gl library. as the gl library is just code that executes inside of the enlightenment process, a problem inside that library can cause just about any problem like memory corruption and crashes. it's not isolated in any way. asan doesn't find any issue because it isn't directly inside code executed by efl or e (as asan adds checking code into that to make sure it's doing things right). youre option now is to use valgrind - but it's slow. it interprets every instruction a process runs and does this checking for ever ything. it may not be able to provide details other than "some code inside libnvidia.so did X to memory Y" but perhaps that memory might be some memory efl passed into gl. if efl (evas gl engine in this case) was passing bad memory into drivers and then they accessed it - i would be seeing your bug too i imagine. my guess here is this memory is internal to nvidia's driver. you're down to valgrind now though.

I was able to reproduce the vt swithching crash after installing the asan versions. Switched back and forth a few times and noticed all windows were black when coming back, and the last couple of times I only got the cursor, and then it froze too. Copied the .e-crashdump file and appended the datetime, then tried switching back and saw the Guru meditation error, and recovery worked. After that I read the logfile and saw it mentioning to use eina_btlog so did that, and then noticed the .e_logs folder and got the crashdumps from there too in case they are different. My .x-session-errors was empty.

i just installed the plasma browser integration extension - it seems to fail (tries to connect and failed - not surprising - it's not under plasma and possibly looking for some service). i'll see if this changes anything.

hmm that extension could be what is triggering things? maybe it's forcing built in browser notifications to use the notification dbus api? i don't think that is actually a bug - but it is triggering a bug in e (the same thing i am saying about the nvidia drivers :)). in this case there is an issue in e/efl somewhere and the job is to find it. such extensions - simple notification api usage by some client should not kill off e. even if they use the api poorly, e should handle it gracefully.

Great info, thanks!
I'll try building with asan as soon as I can and see if I can reproduce. I suspect triggering that same notification (I never saw what it was) will be tricky but maybe I can reproduce the one when toggling two YT videos fullscreen or vt switching is easier.
IIRC the only thing I had autostart which could trigger notifications, other than Chrome, is Discord. The app managing my keybard lights (ckb_next) does autostart but I don't think I've seen it trigger notifications.
I SSH:ed home and just noticed Chrome is running a process/extrension called plasma-browser-integration-host even when under E, could that be messing things up? I don't have that on my work machine which only runs E but don't know if I've gotten the same crash there (vt switching has done it though).
Is there anything else you'd like me to build differently from the Arch defaults, or perhaps some package to install?

just been trying to reproduce your crash in e .. i can't. holding down f when playing a yt video. ctrl+f on any window. holding down f11 in chrome too... toggles back and forth, no issue even with asan enabled in the build which should catch bugs that might otherwise be skipped. :( if you can build with asan - that'd help as i can't see the issue :(

so the crashdumps do seem to be an e problem. will get back to that later.

Thanks for the clarification.

so it seems this happens in e and kde. it seems to hang about more stubbornly in e but the core issue is the same. that to me says "time to talk to nvidia". you could try the nouveau drivers - but YMMV there. another option is to switch to another gpu (eg amd or intel etc.). fyi the double/triple buffering doesn't change buffering - it changes what evas ASSUMES the buffering mode is for calculating partial updates. the best is ti leave it on auto. there is no setting in e/evas to specifically use single, double, triple etc. buffering. it will thus use whatever the driver layer thinks is right (normally triple buffering).

I have had similar, if not the same, issues for months with Elite Dangerous, Doom Eternal, and pretty much any other game doing rendering, and Chrome/Chromium on all my machines running Enlightenment. Most often it happens when resizing and playing a YouTube video. The whole window rendering locks up and I have to resize again to make a few more frames render and keep doing it until it continues normally. If it gets really bad I have to reload with Ctrl+Alt+End and hope it starts rendering again, but that often ends up in a reload loop and won't stop fading back to black until I switch to a vconsole and back, which in turn causes a full lockup and if E itself doesn't force a restart I have to send it a SIGKILL (thanks you enlightenment_start for keeping my apps alive!).

remove unused if condition

change camel case to underscore

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

old and out of date

enlightemnent_open is called by xdg-open and xdg-open is meant to open any file base on mime type -= ie a dir will come up in the file manager, a jpeg will use whatever image viewer is known to handle that like you double-click the jpeg in efm ... and thus executables like xterm will be EXECUTED. thats how it's meant to work. enlightenment_open does what would happen if you double-licked on that file icon. so it's doing exactly what it is intended to do.

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

Ummm.... Where do you type this in? this must be fore your log in so before enlightenment even runs?

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

sorry - didnt see this here. have you tried git master? i'd need full gdb debug -0 no line numbers here... :(

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

Gah! Done.
Thanks :)

Hello Colocasian,
Being the imlib2 maintainer I probably should have made sure to get notifications about relevant phab issues (I think I will now).
Anyway, I just stumbled over the heif etc. stuff.
I have a couple of comments, otherwise it looks good to me.

Raster, first I'd like to apologize and say I'm sorry as it seems you took at least part of this critique personally. I didn't realize you are practically the only one working on this so I think I incorrectly assumed this thing was a "corporate decision" of sorts and reading back I realize I worded this much more strongly than I should have. Didn't even check who was replying to me or who the OP was... Also realized I'm chasing the master branch so I'm very much getting a snapshot of work in progress, and maybe even one that is bad at representing what it will eventually look/function like. I think trying to get work done in this frigging heat and also having to unexpectedly deal with this on my workstations didn't help. ;)

i've plugged in monitors and never seen this. everything should fade out to black (to hide the screen re-configuring with everything now black and back-light dimmed to lowest level), then e reconfigured the screen, then it fades it all back in. all screens are treated the same - desktop or laptop. same thing. the only difference is desktop screens can fade using ddc controls instead of sysfs controls. this requires ddcutil to be installed and the monitor to reliably work with ddc - but for the internal laptop screen it should also work. i've always seen this work reliably. keep in mind that when e fades to black it BOTH dims the back-light to minimum level (0 which may mean completely off for your hardware OR it may just be very dark - if you shine a bright light on the screen you should be able to see some details on the screen if it was just the back-light being off). but e ALSO RENDERS a fade to black - so basically a big black rectangle covering the whole screen that fades in from alpha 0 to solid - this causing all screens to draw black. so e does both to hide everything - that's the point. to make everything as invisible as possible while it re-configures things

Version of E was 0.24.2 built on GIT ID 7d694d6eea
EFL was 1.25.1 and GIT id d6a896ef96

some parts are unfinished. but yes - its very different. it's flat. as i explained - it's what most people demand to be "modern" so having to do it.

wohooo! seems like its fixed now :)

I think this should now be fixed in git.

Maybe it'll grow on me, and some of my gripes are probably just bugs or unfinished parts that haven't been worked out yet. Still feels a bit alienating though.

I don't know what you are talking about... buttons have a shadow and a different color. they press in... when you press the button the shadow contracts and is less blurry so it looks like it presses in. i don't get the "buttons look just like labels" bit... as they don't. see below:

I just updated EFL and Enlightenment for the first time in a long time and I'm sorry but this change hit me in the face like a sledgehammer. It's a manifestation of everything wrong with modern design and this flat trend.

yes :), with the animation disabled I cannot reproduce the issue

Ok, maybe I see it too.
Does the problem go away if you disable "Animate window maximization" (misc.movres.maximize_animate)?

Today, 'Efreet did not update cache' issue, doesn't appear after launching wayland session.
Conditions: enlightenment and efl git master, Arch LInux system.

Try with these steps:

Hmm.. e16 only deals with X11 pointer events and does not use libinput.
e16 does not know of (or at least care about) the type of input device.
Any difference in behavior between touchpad/mouse and touchscreen behavior must somehow come from the configuration of these devices which lies outside e16.
Maybe you can figure out what is going on by trying xev with the different devices.
One thing that may be significant is the time between key press/release events and between repeats (double click).
Unfortunately I don't have a computer with touchscreen to play with.

I understand, it's not priority, ok.
May be some hope here:
XWayland 21.1 Release Candidate Offers Split From The X.Org Server
XWayland 21.1 Standalone Released To Offer Better X11 Client On Wayland Experience
XWayland 21.1.2 is out

Can't tell you what the flickering is - we render surfaces normally like any others. we don't do explicit fences. The input problem is known. I don't know what the solution should be (have ideas). Have not spent any time looking into fixing that. so "I know. ffox has issues". I have other priorities and frankly just don't have the time to look into this - other things are keeping me busy that are neither for wayland or x specifically -t hey are general for e and are on the todo list.

fixed by 7d694d6eea4a599f7d60af4c38f12a6d01fc57fa in git master

Looks good to me.

KDE has added multi-screen recognition, time for Enlightenment ;)

I have now tied to reproduce this, but unfortunately no luck :(

I could confirm this patch fixed the crash.

I didn't have time to go deeper. But this seems to fix the problem. It seems like there was a typo using the not operator in front of delete_me since it was deleting the signal before it was being used.