well they don't REALLY solve it .. they hide it by being even more aggressive at not doing anything when blanked... :) but the massive cpu % being used is still the problem... it should not be using that much.

that's common. it may mean e double-renders or misses a frame every few hundred/thousand frames or so when they diverge enough. i've had mis-aligned refreshes often enough without issues though...

hmm so ONLY when screen is off... please just try intel to see if it goes away. also try software rendering (no re-plugging/cables needed). i'm trying to figure out if this has to do with the nvidia driver blob. right now it SHOULDN'T be rendering anything and that should mean the nvidia blob is not involved while the screen is off. to be sure i'd throw some printf's in src/modules/evas/engines/gl_x11/evas_x_main.c in eng_outbuf_flush() to printf every time a frame is rendered... it should not be rendering, but maybe it is and disabling of rendering is not working? this then might make sense. e tries to render, swap a buffer, and nvida tries to show the buffer but because no vsync signal is happening on displays it sits in some spinlock trying to swap to a screen that is off or to query the buffer state of a new backbuffer before rendering to know how to partial-render. that would still be an nvidia blob bug - it should know screen is off and just insta-swap without vsync.

that is totally bizarre. when scren is on it does the same even when idle? like 60-100% cpu? can you run perf top again and specificall speed up its sampling rates and look at what it says when e's cpu spikes?

these above now freeze the clock entirely so it'll be totally idle (other bits of e may wake up to do things but not the clock now - not to tick over seconds/minutes etc.)

but just waking up once a second to flip the digit should be cheap and not need that much cpu. i actually was wrong - the new flat theme still have a transition - a fade digit out over 0.1 sec ... so 6 frames every 60... with screen blanks and seconds enabled i see:

well well... but how is it using so much cpu? well ok - I can think of something - when a digit flips the clock in the old dark theme uses an animation that makes it flicker in like broken fluorescent tube.

the vsync handling filters out duplicates. what i have seen is they have the same frame count so it only cares about vsync events with a new frame count. so e.g. if you have 2 screens we see vsync from one with frame 123 and then another from the other screen with frame 123... then the next one is frame 124 for each etc. ... if we didn't filter we'd over-render, not "stop rendering" but perhaps there is a logic hole somewhere?

unload all modules, then load 1 at a time? at least that will tell us if it's related to a module or not and if so, which one. another you can do is update your build to current git master... :)

That's odd. I did see a problem with intel drivers. the vsync events provide a timestamp. I did notice that sometimes my intel laptop would freeze - stop animating. I finally figured it out... the timestamp between 2 vsync events went BACKWARDS. so frame 101 had a timestamp BEFORE frame 100 (these timestamps are clock monotonic so should never go backwards - ever). This basically broken the vsync timing logic etc. - i added a check for this in efl git and a fprintf to stderr too when it happens. It's absolutely a driver bug (I talked to the dri devs and they all agree it should never happen but we can't easily figure out why it happens).

well embryo does turn up so something is going through script... i really am not sure what is doing this... something is really odd on your system there.

hmm well something is seemingly animating and using embryo script along the way... what is animating will maybe indicate what is going on... ?

well nothing special there - something from theme is running. try this: remove the cpufreq gadget from your shelf?

Worth looking into, but "I don't see the problem". Apps running CAN cause E to use CPU - if something interacts with the XServer and that then causes E to have to do something in response - this definitely can happen. It then depends on what is happening if E is using too much CPU or not. An idle X session with no apps doing anything. Tjhis is an idle e sesson with screen set to lock after blanking (blanking set to 30 sec, dimming to 10 sec), current git master e and efl:

perf top might be useful. perf top -p PIDOFENLIGHTENMNENT ...

that's why i suggested trying modesetting... as intel driver now may have some bugs on some hardware setups and the answer is "use modestting" if you have issues as no one is going to fix the intel-video driver... :) invalid bug for e as the bug is off in xorg :)

try remove xf86-video-intel and use modesetting

also intel or modesetting driver?

wait - mouse and keyboard don't work. mouse cursor doesn't move around? vt switch (ctrl+atl+f1/2/3/4/5/6/7) doesn't switch vt's?

the issue i know of was with ffox, not chromium. i have, in got, re-enabled setting wm_state to iconic because of this. a bug was filed with ffox but nothing happened. assuming if you sent a request to the wm to iconify that you do get iconified is an assumption you can't make - ffox froze it's ui until it got the wm state change to iconic thus freezing everything. it assumed it would become iconic whenever it requested, rather than knowing a wm can choose not to honor that request if it does not want to.

IF you set it to iconic - they do things like stop rendering, thus why e stopped setting it to keep windows updating when minimized. the problem is that at least one app (firefox) totally broke assuming it will always be made iconic when you press the minimize button when it uses CSD... until then it worked fine as apps just never went iconic.

because apps will stop rendering when iconic ... thus the miniature thumbnails don't update... :)

well i accepted this now :)

its in git

Well ok - it's not that then. In feb I switched back to the threaded vsync by default - there's an env var to switch to/from thread vs inline. threaded is best if you don\t want to miss frames.

that vsync option simply sets the egl swap interval to 1 (ie vsync). ... the animator - i changed it to have an offset of 0.5 frames:

This has now made it to git master... but the work goes on

well in abandoning this .. you did all you have to. :)

glxgears won't tell you if its software gl rendering or not. Normally the gl renderer string says like softpipe or llvmpipe in it and evas blacklists this and refuses to init gl if that is found. Of course this could have changed over time and the blacklist is not working. Most systems made in the last decade can run glxgears in software at 60fps easily... so it's a useless test.

Yes - had to move. LAndlord selling current place. So have spent now 2 weeks packing and now unpacking... :)

done. sorry. busy with a house move... :)

how about some #ifdef XIM_SUPPORTS_CURSOR ? at least keep the code - and some comment with the xlib bug and some of the relevant backtrace? i'd rather not remove tjhe code completely

can't do this - xdg stds require this to be translated...

something is forbidding installation of the service file where dbus says service files should go

will make the suggested changes too

because our full opengl code was written with glx as the display system binding/abstraction. drm/wayland are not x. they don't have glx. egl is a portable binding that works across all of these. our gles code was written with egl as the binding as there is no glx one for it and thus is portable. if gl-es had been universal at the time when i wrote the gl and gles support.. i'd have just gone for egl + gles to save work and time and effort. it was not. egl+gles was universal on embedded systems. full opengl never existed universally there. glx+full opengl was universal on x11 desktops/laptops etc. - if they had any gl support. over time this changed. some embedded systems now can run a full gl implementation and ALL desktops/laptops now can also support egl+gles. so egl+gles is the universal "works everywhere" combination - works in x11, wayland and directly to drm/fb. i'd actually like to get rid of the glx/full gl code just to have less to maintain now as it's basically a historical artifact.

<vtorri> raster linux has added statx() function 5 years old. It allows to get the creation time. Is it possible to add that feature to eina file ?
<raster> vtorri: needs a feature detect
<vtorri> raster it add a member at the end of a private struct (Eina_File in eina_file_common.h) and in a public struct (Eina_File_Stat)
<raster> i'm not so sur ecreation time is always that useful on linux/unixen
<vtorri> and of course feature detect
<raster> it will require filesystem support it too
<vtorri> it can :
<vtorri> when a photo was created
<raster> but the way many things do saving/overwriting means modified time == creation time
<vtorri> for example
<vtorri> it helps me on Windows to know when i have taken a photo, to organise them
<vtorri> and on Windows, this exists since XP
<vtorri> statx was added in glibc 2.38 according to man page
<raster> well that assumes it keeps its creation time from the original files eg from a camera
<raster> and doesnt lose it along the way
<vtorri> of course
<raster> eg you cp the file over - it'll get a new creat time
<vtorri> it depends on the file system
<raster> when things save files like cfg or text files in vi/emacs etc.
<raster> tey use atomic replace
<raster> so write brand new file with file.tmp
<vtorri> on windows, it's possible
<raster> then rename() that file on top of the original file when written in an atomic replace
<vtorri> since the feature exists in fat and ntfs
<vtorri> on linux, i don't know
<vtorri> raster i'll try to add that
<raster> anyway - if create time doesnt exist - what to do?
<raster> ie no statx
<vtorri> set it to 0 or modified
<raster> "or" :) need to decide which :)
<vtorri> this must be said in the doc
<vtorri> i would said 0, and the user know there is no creation time and deal with that
<vtorri> for a file explorer it can either write the modified time or another text
<raster> actually
<raster> that's kind of a problem
<raster> you are right NORMALLY
<raster> but there are many linux diustros that literally set modified tiems on files to 0
<raster> ie jan 1 1970
<raster> and this actually caused bugs in efl.. as it didnt expect anything to have a timestamp of 0 :)
<raster> (caching issues)
<vtorri> ((time_t) -1)
<raster> well that might work
<raster> as its in the future...
<raster> and 1 second before the end of time itself :)
<vtorri> of course, doc should mention it
<raster> yup
<raster> but its choices to be made
<vtorri> of course

@herb - can you commandeer this back and fix the title and content again?

oh wait @herb - not you. it was @fwxpdsz12

hey @herb ... it looks like your account was hacked? someone stole your cookies or password.