@segfaultxavi hehehe - but it is true. we shouldn't ecourage use of things like ecore_x - it leads to non-portable apps that don't port to wayland (or fb/drm+kms or windows or macos etc.) :)

don't worry about doxygen for ecore_x ... ecore_x is essentially an "internal x convenience/porting layer". the only intended use is e and efl itself. no one else. so no need for docs.

0802f4dc95603b2c95c854c627fd297dd95412aa fyi

It seems that killing efreetd (or crashing it) leaves the socket in place, so new instance has troubles to bind to it.

unlink_before_bind is an option in the efl.net api basically it's something that cna be used to forcibly take over a socket even if something is still listening on it. it's not actually USED in efl anywhere so it's an optional code path. you can ignore this as it's not relevant because it's not enabled.

if you restarted e - e may have deleted the old xdg dir and replaced it - oddly with a new xdg dir of the same name. the old efreetd will eventually die when all its clients go away. i changed e to not delete on shutdown but to have enlightenment_start do that instead.

this looks right to me - the file_mmap_get should fail as the file hasn't been opened yet.

This (plus series) does fix async head load for sure. :) now startup time for my test of about 1000 images starts 10x as fast in creating image objects because the file opens happen in the thread not in the main loop. (well it gets to elm_run 10x as fast). so my takes is all good - it's a big step back in the right direction. :) assume this to also approve the dependencies too

@zmike - awesome! :) fantastic man. i'll look at it tonight

a blocking accept? that's just stupid. that should not be happening. we wont be doing an accept unless the fd says its available for reads.

well i put in a "don't crash" workaround to the crash above... but without knowing the full flow of how it gets there, that's the best i can do.

ok after monitor switched off in 02-monitor-switched-off.txt:

you first log doesn't seem to tell me when it suspends or resumes. no systemd? i don't see any SSS: lines that would tell me it's suspending/resuming.

accepted... 19fe001f4f28287e0593ac4ac575e71e48cd0edd

in this case the xrandr tool will not be very helpful. the stdout log from e will be. the likes starting with RRR specifically. does x report screens chnanging/being plugged/unplugged before/after suspend/resume in the log? what does it say?

but that's not what the action does - it shuffles up and down by screen number which is dictated by priority. it's NOT a "move window left or right one screen" which would do what you want. :) we don't have such actions... :)

that's better :) now what do you want me to do with this. if i snarf this from phab using arcanist the commit ends up being from me n the log (not you). Can you give me an email line to use as author like:

ok. sounds good. let me actually just make a few comments in the code :)

why not a range of 0 to 100? you know that 0 could be black or could just be very dim. it varies from hardware to hardware. also lowest level backlight could be hit at 10/100 if the backlight device only has 9 steps... i've seen backlights with 8 and 5 levels before... others i've seen with 8000 levels or so... others with 255, some with 100 (at the kernel interface). the whole backlight system just simplifies it to 0.0 to 1.0 at the api level in e as there is no way to know when/if the screen actually goes totally off or if 0 is just a very dim value without experimenting on each and every device. if we're suing xrandr as the controller (which we do if it offers it in x) then nothing in e sees even the number of available levels - it's also abstracted out like inside of e by the xserver/xrandr.

that's because you have your screens backwards. the bindings change screen count by 1 or -1 ... screens are numbered based on which is primary or not (0) as well as the priority value in the screen setup - highest priority is sorted to start of screen count. if priority is the same then it's in order of x value .... then y value for screen location.... :)

I see suse has an odd package naming scenario there... :) but yeah - missing devel pkg :)

have you thought of providing the openjpeg devel pkgs like all other devel pkgs for deps... or disabling the jp2k loader? :)

overall cool - see your other patch with the json ifdefs for my one disagreement. :)

i don't see why the json support needs to be ifdefed out of edje_cc - people can compile edj files with vg/lottie support in them without special features needing to be in efl. they can't TEST/SEE it... but this i think is important for CI and other reasons to keep the support in edje_cc always - just runtime support should have it be blank and/or display errors when trying to load lottie vg parts... :)

methinks it's a typo and it is meant to be foreach" since the above loop does an EINA_LIST_FOREACH on the cache list... § do the same to the file collection hash which are where > 0 refcount files are stored (as there is no ordering there as they are all active - it's not an LRU (least recently used) list used for keeping things around speculatively in case they are needed again like the _edje_file_cache ...

to do what you suggest i think is going to require hacking phab itself... and that might be going too far for this. :(

what was missing? the setuid bit? the makefiles - or well ninja files DO add the setuid bit on install. we have a post install script hooked into the build to go do just that and set the setuid bit. my bet is your packaging removed the setuid bit. some anal packaging systems like to do that and unless you go manually add it back in the packaging ... it remove sit. which is why my firest response was - probably a pakcaging issue. i know we set the setuid bit... because i added it to the setuid exe list to get the bit set and it's set here after "ninja install" and i didnt do any hacking around to set it. when you have these kind of issues first and always - assume packaging has broken something because assume that devs like me have already had the setuid bit set on install because i do a "sudo ninja install" to install e and it all works for me ... no packaging in between my install and me running things :)

yeah - what @zmike said . setup.py - not a good choice. the general idea i like. i dislike there being setup.py and setup-examples.py. if this is going to be as xomplex and becoming python i might say this should be a single script with something like

as i mentioned before - you'll probably find it's a packaging issue - missing files or setuid bits. find the enlightenment_system binary and check.

when applying compositor settings e restarts. that'll now get you back to the 0, 0 desktop. that is expected.

qeqweweqweqweqweqw

totototot

blah

and... again

one more time...

tetetetetetetest

xxxxx

boop

blah

sdfwefwefewfwefwefsfcsdcfwe

xxxxxxx

boooboo

try2

blah?

add comment

wowowow

blkahshswdf

tetetetet

ttt

blah blah

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.

blah

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.

hmmm i was wondering if perhaps somehow there is a mixed up config with different bits of config saying different things (like which theme to use).

WTF? ... that's just odd. both the dependency walker thing and the pkg config path fixing it.... you definitely had a problem for sure.... but it's been kind of hard to know where to look at fixing it because it's so odd. :(

i'll call this resolved then...

it seems to have applied anyway. according to that output.

are you sure you compiled and installed the patched efl? the valgrind log - specifically the first entry is the same as before even though i explicitly have code there to NOT free the data it's complaining about and telling it to enable that code... your log would make sense if you hadn't installed the patched efl and were running the previous unpatched one... ?

you need your efl build tree. you need to apply that patch in the efl build tree then recompile + install efl. to do that:

cat you try this patch?

just so we have it here...

aha! that's more like it! :)

waaait .. we dont need massif. we need memcheck... :)

I fixed up our loader modules a while back (a whole bunch were compiled in always as opposed to being modules like they used to be) thus bloating out our runtime deps and dirty pages... so the issue here is not what is being linked to but link ordering if my quick read of the above is right? as @bu5hm4n says - that is one of those details meson itself handles - we provide more abstract sets like "link to these here". we don't determine ordering (well it's not meant to determine ordering - that's kind of the point of meson to not have us worry about every compiler,platform and requirements of ordering of linkage etc.) ?

Scrot issue. It draws a selection box. To do this it draws to root window with xor pattern and "include inferiors" thus basically scribbling all over the screen however it likes with no respect for the fact the compositor has placed a window above all others in the screensaver overlay layer. Thus it's scribbling all over where the compositor draws. This was fine to do in the days before compositing. It stopped being fine once you had compositors drawing the screen. What you have is simply a race condition where the xserver switches from using copies to buffer exchanges for displaying the screen buffer. that means with copies, the xserver COPIES the image from the gl backbuffer to the screen - thus overdrawing anything scrot managed to scribble. when it goes to swapping, the xserver will SWAP buffers. that means what buffer is displays is a pointer. "display buffer A", then switch to "dis[play buffer B" and basically the pointer is swapped. the memory that USED to be displayed on the screen now is recycled for a new backbuffer to draw on. evas (e) takes advantage of this with the buffer age extension in gl to know how old the buffer is and only draw the areas that updated.

fixed by d23615046b92333d7f27f97c040a6666a65a7aa3

Don't design the menu from elm menu.... certainly not from theme. Look more at e's menus for inspiration. A menu has to sanely be able to do check and radio items and ALIGN icons, radio/check indicators as well as submenu indicators/arrows.

ok. that says that pp->program is NULL, yet the only code that creates pp (allocates it and fills pp->program) can't fill it if pr were null (it'd crash there when created) so... the only thing left is that it's some kind of memory corruption. that pp struct is corrupted in the heap and the program member nulled out. at this point... you need valgrind or asan.

in git just recently

move to here - i can't reproduce any of the above issues. works perfectly for me. what os AND video drivers?

can we move this thread to T3438 ?

i am not sure what your problem is - i'm staring art it working right now in front of me on am amd card. i have had it work fine plenty of times on intel too. can switch x->terminology and back, vt to terminology and back...

T3438 has nothing to do with this and it works just fine for me in a tty. i do try it every now and again/ i can vt switch all i like. have been able to for a long time. but that is the other ticket and i'm staring at a "can't reproduce"... so i call that one resolved long ago etc. but irrelevant to this.

ok. a segv... now it's time for valgrind or asan to tell us more...