+1 here too Drag-n-Drop does not seem to work while more and more web browser features depend on this :-)

Great! efreetd might be a pain for a while. If you submit patches even cooler! If there is time and I can help out that wouldn't be a problem. Good to hear of some interest and work on it.

I ported both to NetBSD, I use it, but I have some issues. I plan to contributing the patches to overview.

Can anyone please comment on the state of EFL and E etc on NetBSD? I'm really interested to know.

Finally efl-1.25.1 on NetBSD 9.1 amd64 with pkgsrc-2020Q4 works fine, no more efreetd segmentation fault.

@cederom what is the status of that task ?

Thank you @ProhtMeyhet :-)

@raster you helped me a lot to get things done, and I am grateful for that, thank you, I do not want any shitstorm here, sorry, I do not want to destroy anything, no worries, I am just looking for a solution to make things portable as free and optional alternative to existing solution, preferably that could be selected with meson at build time. But existing solution is hardwired to only one OS out there, Linux, that creates its own standards ignoring the rest, thus becoming less and less open, while there are others solutions that make things work for everyone.

See T6947 and @devilhorns branch which is outdated. I don't know the current state.

Fully agree - all functions and dependencies should be totally optional - except dependency on systemd is quite the opposite - it is a hard dependency on Linux OS and whole project portability blocker when it comes to Wayland - so anything new that makes E work with Wayland should be optional and portable :-)

FYI ... i'm very very very much against adding more dependencies. after decades of users complaining bitterly about needing any dependency.. any new dependency has to come as being totally optional OR a very very very good reason to use it. so basically don't expect existing logind code to change as the only deps it adds are those that are already on the system.

After discussion on WLROOTS GitHub [1] is seems that LIBSEAT would be better ELOGIND replacement rather than using whole wlroots :-)

Thank you @devilhorns @raster I have asked this question on wlroots github the best place to get quick and reliable answer if we can use wlroots and our own renderer :-)

we can;'t use wlroots because it also includes a renderer of its own and that would mean we drop our own (evas) and that would essentially kill off all of e as everything u see is rendered by evas. as long as you have your own renderer something like wlroots is pretty much a no-go. i haven't looked in DETAIL though so maybe there is some way to bypass using the wlroots renderer but then this spiders out to other bits we then can't use etc. etc. etc. and eventually we find we use very little of it ans spend a lot of effort in impedance mismatch handling.

In T8866#154744, @cederom wrote:

The question is why don't we use WLROOTS and SEATD so the project gets portable and does not contain hard references to Linux only solutions like systemd/logind? If we had that solution Enligthenment would already work using Wayland both on Linux and FreeBSD :-)

Do you know these solutions? Is it a lot of work to add another WL glue (wlroots+seatd)? Any sort of estimate form experienced developer would be nice to know :-)

The question is why don't we use WLROOTS and SEATD so the project gets portable and does not contain hard references to Linux only solutions like systemd/logind? If we had that solution Enligthenment would already work using Wayland both on Linux and FreeBSD :-)

Thank you guys! All is clear now. I will continue further discussion on https://phab.enlightenment.org/T8866 :-)

In T8867#154720, @cederom wrote:

Still the core question remains - if EEZE is a mandatory requirement for DRM? If not then DRM code does not respect meson configuration :-)

Currently, the DRM implementation in EFL is coded to use Eeze for discovery of the drm card and other devices. Systemd or elogind is also a requirement currently. As I do not use *BSD, I would be unable to code support for that (as I cannot test it), however if you would like to provide patches then I would be happy to review.

Thank you @arrowdodger for the hint on ConsoleKit2 [ck]. I am a bit confused - is this elogind replacement? I have this installed already but this does not seem to solve my problem with E..

elogind has similar DBus interface with one that consolekit2 uses. The latter is present in our ports, so maybe you should try it.

Allright it turns out that E/EFL when it comes to Wayland it hardcoded with Linux's systemd/logind/elogind. This sux :-) But there is an alternative called SEATD that is portable by design works already on FreeBSD and Linux and it meant as replacement to elogind.

With the changes proposed above the package builds, it contains several modules, but it cannot connect to input and cannot open a device what ends in not being able to create a compositor. As I have mentioned above sway and wayfire works fine here so we need to work more :-)

Hello @Peter2121 can you please take a look and give some hints on how to evade clone / unshare / setns which are Linux only syscalls? Details above :-)

ACK! I also prefer to patch upstream/master :-)

Then we have src/modules/wl_drm/e_mod_main.c:

../src/modules/wl_drm/e_mod_main.c:786:17: error: use of undeclared identifier 'KEY_F1'
       (code >= KEY_F1) && (code <= KEY_F8))
                ^
../src/modules/wl_drm/e_mod_main.c:786:37: error: use of undeclared identifier 'KEY_F8'
       (code >= KEY_F1) && (code <= KEY_F8))
                                    ^
../src/modules/wl_drm/e_mod_main.c:791:22: error: use of undeclared identifier 'KEY_F1'
        vt = (code - KEY_F1 + 1);
                     ^

Some more problems in src/modules/xwayland/dnd.c:

../src/modules/xwayland/dnd.c:463:20: warning: implicit declaration of function 'socketpair' is invalid in C99 [-Wimplicit-function-declaration]
               if (socketpair(AF_UNIX, (SOCK_STREAM | SOCK_CLOEXEC), 0, fds) != 0)
                   ^
../src/modules/xwayland/dnd.c:463:41: error: use of undeclared identifier 'SOCK_STREAM'
               if (socketpair(AF_UNIX, (SOCK_STREAM | SOCK_CLOEXEC), 0, fds) != 0)
                                        ^
../src/modules/xwayland/dnd.c:463:55: error: use of undeclared identifier 'SOCK_CLOEXEC'
               if (socketpair(AF_UNIX, (SOCK_STREAM | SOCK_CLOEXEC), 0, fds) != 0)
                                                      ^
../src/modules/xwayland/dnd.c:463:31: error: use of undeclared identifier 'AF_UNIX'
               if (socketpair(AF_UNIX, (SOCK_STREAM | SOCK_CLOEXEC), 0, fds) != 0)
                              ^
6 warnings and 3 errors generated.

When do you plan to push the patches to master and would they get to a next release and when is the next release planned?

When do you plan to push the patches to master and would they get to a next release and when is the next release planned?

Still the core question remains - if EEZE is a mandatory requirement for DRM? If not then DRM code does not respect meson configuration :-)

Now its time to fight some bugs in Enlightenment :-) It recognizes EFL to have Wayland support which is a great success because that was a blocker. Some new issues shows up when building E with Wayland support :-)

Thank you! This helped me a lot and progressed into a state where whole EFL builds on FreeBSD with active WL+DRM configuration. I have some issues with Enlightenment but I hope to solve them soon. Wayland and hikari/sway works on FreeBSD so I hope to work with my E here too :-)

Now I have this: ../src/modules/ecore_evas/engines/drm/ecore_evas_drm.c:23:11: fatal error: 'Evas_Engine_GL_Drm.h' file not found. I guess that header is part of EFL?

After fixing the EEZE build problems, following linux related problems occur for WL+DRM build on FreeBSD. Are these really necessary? Can they be provided with EFL? Should we add them to FreeBSD?

I prefer that netstar test it and pushed himself. It seems that he changed my patches. Anyway, before push it should be tested :)

Peter updated me with a hint that EEZE can build on FreeBSD when libmount is disabled in meson and following patch applied on top of EFL-1.25.1. This is true! Thank you! :-)

Replacing [engine_gl_drm] with [gl_deps] does seem to fix the meson issue [1] :-)

I have created a separate report for DRM enforcing EEZE although this EEZE is explicitly disabled with meson switch: https://phab.enlightenment.org/T8867

actually i think this is just old and already long fixed as we have a macro for this:

lua 5.2 is explicitly supported in efl. 5.1 and 5.2 are supported. .53 and newer are not and 5.0 and older are not. lua does regularly break api/abi - so we have to explicitly change code to adapt to new lua versions. you can see in meson.build in the top dir: