so much needed fixing... i just fixed it :) i suggest you check the patch after i've fixed things... :)

fixed by fc5ec2b00c102f8bd667346151b3206c5e140ebb

how interesting. 1.2 seems to cause this. it seems to create a massive size of something and eat through memory until it runs out of ram or something. i have to have a look.

in git with b5b0222ae0569526f96af1876dd162efcb4ca937

fixed by 662caef9844adbf335a8ae6e47ebc0eacb78692f

well i looked more - and the above is right - e reads the shape and it's not empty.. but i found a problem... e itself MODIFIES the shape input region for the window... it can do this for managed windows but for unmanaged override-redirect .. it should not. it is an e bug where it modifies the shape the client set before e itself then reads back that shape to find it reset... so

correct. the above link explains in gory detail what i see on the wm side - no shape input is set. if it intends to do this.. it somehow fails along the way - by the time it gets to the wm end there are no shape input rectangles other than the whole window rect itself. as this rectangle-overlay is a proprietary binary. i guess i could disassemble it and so on but there comes a point where i don't have the time and go "ms - your code, your problem" :)

scroll to the end. i've reported it as best i can to ms as there doesn't seem to be some formal "file a bug" thing for teams

see all my comments. you don't introduce a new type for the cb - you change an existing one. you need to introduce a new one. you can go casting ptrs around inside efl but the api has to be cleaner than this. :)

see all my comments. you don't introduce a new type for the cb - you change an existing one. you need to introduce a new one. you can go casting ptrs around inside efl but the api has to be cleaner than this. :)

fixed by 173c9cdbe161a5a1abd1a76756ebfa77c2767fd2

I saw this - marked it. Just haven't gotten to it. :)

fixed by 7dcaab26cf6643fae0401c38b394d821370681fd

closed by 30207a61658509d810c508d5ee8b034c1aea451c

Your other issue T7045 could easily be the same problem - it's taking so long to update caches that E gives up and complains. I don't know for sure because unless I can consistently see the problem, reproduce it and see what is going on... I don't know. In this case It's just that it's slow. Most of the slowness is due to eet's string dictionary and adding 10000's of strings to it. I have a speedup with a cache right now that has taken this rebuild from 80sec down to 30sec, but I think I can do better.

i can't say - i dont see any issue when closing here. i had to set up a new config for the clone (well change settings in screen setup - that is a new screen config there). ... i dont have anywhere near enough information to say anything more. :(

ok - hoping ot get the confirmation from @maderios ... I didn't write efreet so I have no idea what algorithms and logic it's using here... but i suspect it may need a rewrite (which it has needed for a long long time) to do things like not decode the cache files at all but directly mmap them. it decodes them right now and has always used a lot of memory as a result. if you have lots of icon themes installed or very very large ones - even if you don't use them, efreet may be keeping indexes in memory for these...

actually ... i just installed some of these... it just was SLOW... writing out large cache files as these themes have a LOT of files/icons ...
like it took 1m20s on my amd5950x ... can you just wait a bit and see if it eventually finishes and this is simply a performance issue? I just ran:

you don't need to kill enlightenment - you need to use gdb to attach to the efreet_icon_cache_create process or at least start with strace like

You would need to trace the process to find what it's doing. strace, gdb + get backtraces. if i saw this happening i'd be debugging it. i don't see it happening. the only things i can think if might be it's a thread deadlock (something stuck on a spinlock) or its some loop - and a loop here i might imagine is in your filesystem - e.g. symlinks that create a loop. so e.g. a symlink that goes back to a parent directory that is in a child directory.

:)

From E's point of view a TV is a monitor. E doesn't know it is a TV at all. It's just another HDMI (or DisplayPort or DVI etc.) output that has modes available (eg 1080p@160hz, 20160p@30hz, 720p etc. etc.) and is configured to be on with some mode and some rotation and is relative to another screen (left/right/above/below etc.) or is closing some other screen. In case of cloning E has to try choose the same mode for both screens. It will try choose the nearest one if the same mode is not available.

fixed by D12297

let's link the patch :) D12297

there is no reason existing config would affect this at all... the config is done in memory with the gui modifying the in-memory config then the config is later written out to disk. :(

I just set one screen to clone the other. it worked for me... I normally have one screen side by side with the other all day too...

oh. i missed this! thanks for the ping!

if you have trouble switching vt's and e is running in x11 as it should be ... then vt switching is an issue` for your xorg server/driver - enlightenment doesn't do this at all. it's entirely handled internally by the xserver. e16 isn't a compositor thus it wont be using the gl driver stack ... so the way rendering and buffers display on the x server side will be different.

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 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.

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.

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).

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.

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

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.

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:

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

:)

i dont see this and my screensaver kicks in a lot.... same as your git efl/e - i haven't seen this. default theme too...

i seriously think you have a driver bug. that vsync option just sets eglswapinterval to 1 instead of 0. that means egl (the xserver end of it) will wait for a vsync to swap buffers. you could try build efl with full opengl instead of egl but full opengl will use the glx swap interval api instead... so it may just end up the same. animators are still timed to vblank/sync events if possible on that platform etc. even without vsync enabled.

Well I'm a bit stumped - without poking round to see more detailed info ... :|

@rafspiny ?

:) \o/ :) cool!

good point - but shouldn't this be fixed in eet_eina_stream_data_descriptor_class_set() ?

i assume this is for a partly downloaded file or something?

this was fixed by avoiding heap allocations as per thread here.

At ome point i need to come back to lock screen and expanding what it can do, but i'm busy with color classes and related stuff right now.

it's not fake. it is real. pulse says so. pavucontol happens to choose to filter these out and hide them, but they are real pulse entities. emixer now does also filter them out

c7264e9ed5eb1725d926cbc76324bfbb9bfc6da9

fixed by D12276 ?

cool

do you want to add a test in this commit and update it or submit another one after this?

well by itself this turns into compiler death... as some of the previous ones break builds or add warnings - i didnt test this together with the others ... just some of the errors:

seems to work fine :)

This leads to warnings redefining things:

works :)