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! :-)

I can see these patches are not in master yet.. can I push them or the author should push them? :-)

When patches are in master we will close the issue :-)

--- src/lib/ecore_input/ecore_input_joystick.c.orig    2020-09-18 18:38:25.837170000 +0200
+++ src/lib/ecore_input/ecore_input_joystick.c    2020-09-18 23:23:45.853939000 +0200
@@ -3,7 +3,7 @@
 #endif
 
 /*FIXME: change OS specific value */
-#ifdef __linux__
+#if defined (__linux__) || defined (__FreeBSD__)
 # include <linux/joystick.h>
 #endif
 
--- src/lib/eeze/eeze_net.c.orig    2020-04-07 22:40:50.274632000 +0200
+++ src/lib/eeze/eeze_net.c    2020-09-16 22:29:00.000000000 +0200
@@ -5,6 +5,7 @@
 #include <arpa/inet.h>
 #include <sys/ioctl.h>
 #include <net/if.h>
+#include <netinet/in.h>    // Need in FreeBSD
 #include <unistd.h>
 #include <Eeze_Net.h>
 
@@ -199,7 +200,7 @@
    eina_stringshare_replace_length(&net->broadip, ip, INET_ADDRSTRLEN);
 
    if (ioctl(sock, *i++, &ifr) < 0) goto error;
-   sa = (struct sockaddr_in*) & (ifr.ifr_netmask);
+   sa = (struct sockaddr_in*) & (ifr.ifr_addr);    // https://github.com/pali/igmpproxy/commit/158307bd0b69db714b5a27e77792c160b1af165f
    inet_ntop(AF_INET, (struct in_addr*)&sa->sin_addr, ip, INET_ADDRSTRLEN);
    eina_stringshare_replace_length(&net->netmask, ip, INET_ADDRSTRLEN);
 
@@ -221,7 +222,7 @@
    eina_stringshare_replace_length(&net->broadip6, ip6, INET6_ADDRSTRLEN);
 
    if (ioctl(sock, *i++, &ifr) < 0) goto error;
-   sa6 = (struct sockaddr_in6*) & (ifr.ifr_netmask);
+   sa6 = (struct sockaddr_in6*) & (ifr.ifr_addr);    // https://github.com/pali/igmpproxy/commit/158307bd0b69db714b5a27e77792c160b1af165f
    inet_ntop(AF_INET6, (struct in6_addr*)&sa6->sin6_addr, ip6, INET6_ADDRSTRLEN);
    eina_stringshare_replace_length(&net->netmask6, ip6, INET6_ADDRSTRLEN);

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

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

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

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?

I ask just to know if it is better to provide those patches with local port update or it is better to wait for a next release that could already have all patches :-)

Thanks :-)

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?

You should ask netstar ;)

Anyway, I'm opposed to patches management in port. It will slow down the updates. If the patches are OK - they will be merged in master. I hope, netstar will have some time to work on it soon. Please, add him to the list of subscribers.

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

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

Yes, Eeze is a requirement for DRM. It is used to discover the system drm card to use, and for other things also. If you would like to provide patches for using drm without eeze, I would be happy to review them for you.

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

Please let me know when master is patched so I can verify build of EEZE+DRM on FreeBSD without local patches :-)