i can't explain why. i can't reproduce. i am just saying the issue i see is not related to efl. it's universal.

How can you explain the images I've sent in this ticket? The shift is present in your test EFL app but not present in GIMP. Maybe, indeed, your test is not relevant because of a problem in VBox X driver. But the problem is constantly present for me on three PC with different versions of X drivers. And the problem is neither present in QT apps, nor in GTK+ apps (nor in FLTK apps, nor in FOX apps, nor in pure X apps, ...) I don't think that all GUI toolkits fixed in their libs a known bug in FreeBSD X server ;)

yes. host run e too, but the pointer inside vbox is emulated by vbox. it's drawn/rendered internally - you can tell because the pointer gets clipped by the framebuffer boundaries inside vbox and doesn't overlay the window/fb bounds. so host poointer and host wm doesn't matter... but the fact i see pointer problems/bugs in vbox with fbsd makes me think there is some issue there that is fbsd related here in x and/or vbox drivers in fbsd. ...

raster, do you start VirtualBox using Enlightenment on host? If yes - what pointer do you use in E? Maybe there are two effects together...

well i still am as above. in vbox + x11 + fbsd there is a definite bug in xorg or vbox where the pointer is offset but it applies to all pointers, not just e. i otherwise don't see the bug. 2 themes (default or the new flat one i am working on). i can't go fix something i can't see and investigate...

I did not check since 11/03 as nobody indicated any commit, related to this problem.
During my tests I checked with two themes - the default one and my theme, based on the default (buttons on left side of windows and some small tweaks). I did not see any difference between the two themes.

I can see the cursor jumping on Linux. I think it might be theme related? I see this behaviour with Simotek's ice theme.

Does this still happen?

...and the shot of GIMP:

So, finally it builds correctly with:
cc x.c -o x pkg-config --cflags --libs elementary

I would like to see the detailed instructions about building the test tool.
After manually adding ALL include dirs of EFL as -I flags, the compiler is OK, but the linker cannot find some references:
elm_policy_set, elm_win_util_standard_add, elm_win_autodel_set, evas_object_evas_get, evas_object_rectangle_add, evas_object_color_set, evas_object_size_hint_min_set, elm_win_resize_object_add, evas_object_event_callback_add etc...
The flag -L/usr/local/lib is present, the libs are installed in /usr/local/lib/ecore, /usr/local/lib/edje, etc.

Once again, raster, I have NO problems in non-EFL apps.
It's OK for me in GIMP, no problems at all.
If I choose 'Application' options in 'Mouse Settings' of E - I have no problems in X11 neither.
I'll test your tool this evening.

well in this case i see it in gimp where no efl or efl pointers are involved. efl displays the same offset too fyi. :)

I remember having something like this before, which was in the end edje, not positioning the image correct. (Just my 2 cents).

actually some more testing... gimp show the problem with its pointer in vbox:

well damn. i can reproduce this in my vbox fbsd vm.. wtf? well not quite. pointer is 10pix up and to the left of the hot spot.

Ah, sorry, another PC with the same config (FreeBSD 11.3, OpenGL, Nvidia)

another post

...and I can reproduce this problem on another post with the same configuration.

If it helps - I'm using OpenGL acceleration with NVIDIA driver.

In T8622#151024, @Peter2121 wrote:

I am not sure that it is really FreBSD specific, but I cannot test on Linux now.

i cant see the problem with default or flat theme... :/

i doubt this is bsd related...

I am not sure that it is really FreBSD specific, but I cannot test on Linux now.

I've just tested the last versions of EFL and E from git.
Everything works fine till I kill -9 efreetd process (I think that this situation is rather simple to reproduce). Then I have efreetd restarted, but in a strange state, not responding, and two zombie processes (update cache and desktop). Repeating multiple kill -9, finally I get a working efreetd, restarting E reconnects it to efreetd.

0802f4dc95603b2c95c854c627fd297dd95412aa fyi

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

I've just tested the new version on my test laptop. The situation is definitely better!! :)
I have only one instance of efreetd running, E communicates correctly with this instance, the cache is correctly updated. Restart of E does not change this situation - everything continues to work correctly.
BUT!! There is still one problem. If I kill efreetd process - it is restarted automatically, but then sometimes (not always!) it freezes, producing two or three zombies. If I kill it again - a new efreetd is started, but then it crashes (or exits) immediately and there is no new instances created. If I restart E or start another EFL app now - everything comes back to the correct situation. It seems that killing efreetd (or crashing it) leaves the socket in place, so new instance has troubles to bind to it.
The thing I don't understand - if the socket is not deleted and not unlinked - how can the situation come back to the normal state?? As I understand, with the current logic, a killed (or crashed) efreetd will prevent another instances to work...
As about deleting working socket - I cannot produce any strange effects with my test program. If I delete a working socket - the server and the client continue working as they worked before deletion, a new instance of server creates a new socket, a new instance of client correctly communicates with the new server (so I can have two pairs client-server working correctly using the same socket name, but different FDs).

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.

I could reproduce blocking access with my test program, but not in 100% of cases.
The key point - unlink active socket and rebind it. Sometimes the old server and the client connected to the old server continue working correctly, sometimes, stopping the second server blocks the communications with the first one.
Anyway, it seems that incorrect unlink is the root of the problem as multiple servers on the same socket is definitely not a good configuration. I see the conditional unlink in _efl_net_server_unix_bind of efl_net_server_unix, but I don't understand how and where pd->unlink_before_bind is set (it seems that _efl_net_server_unix_unlink_before_bind_set is used for it, but I don't see it used in EFL/E code).
There is a good article on the subject:
https://gavv.github.io/articles/unix-socket-reuse/
A workaround proposed on Stackoverflow:
https://stackoverflow.com/questions/7405932/how-to-know-whether-any-process-is-bound-to-a-unix-domain-socket

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.

It seems that on manual restart of Enlightenment (Ctrl-Alt-End), EFL does not read correctly XDG_RUNTIME_DIR.
The variable is set in .zshrc, manually started efreetd uses

/var/run/user/1001/.ecore/efreetd/0

Enlightenment started using startx uses it too (at least, it tries), but after a manual restart of E I see another efreetd process, using

/tmp/xdg-g5E9qA/.ecore/efreetd/0

and in the same time the first efreetd process becomes frozen, the BT is the last I've posted (efl_net_accept4).
According to sockstat, Enlightenment is connected to

/tmp/xdg-g5E9qA/.ecore/efreetd/0

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.

So, the new version does not crash anymore, it freezes.
Started from command-line, after some time running efreetd does not respond on Ctrl-C neither SIGTERM.
Backtrace:

well i put in a "don't crash" workaround to the crash above...

Thanks! I don't see any patch attached, is it in master?

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.

Valgrind works better on another PC, log attached.

One more backtrace of efreetd crashed:

Some changes here:

1. I removed --warn-unresolved-symbols from my LDFLAGS
2. I rebuilt all from Git with debug CFLAGS
3. I removed additional search icon dirs from E config

testing a bit more, this script is very effective for stopping e for up to 5 seconds for me. First send a via notify-send which returns immediately, start date and then shellementary. Needs a bit higher load and a hardware accelerated video playing. Browsers like Firefox and Chromium are helpful as well. Restarts after 900 seconds which seems enough to purge the kernel cache of shellementary and its librarys.

For me I've found a relatively reliable testcase for this: shellementary. When I play a video, have a browser open and a system load roughly equal to the number of cpu cores, e hangs for up to 5 seconds when opening it the first time. So it seems either e or Xorg is waiting for the creation of this window, but shellementary sometimes takes too long (maybe on memory init?)

Do you have something like valgrind? The future seems to be completely empty other than the next and promise which is weird.

I could catch the same crash:

Fixed in Meson, tested OK. Hope the new version of Meson will be released soon.