Hello @netstar this is fairly old thread and some new things happened in the meantime :-) Both X11 and Wayland works fine on FreeBSD already :-) X11 is considered obsolete and I guess the move towards Wayland is happening now (plus KMOD/DRM graphics acceleration infrastructure). Upcoming 13.0 will improve things a lot and I hope we can move forward with E+W.. It would be nice to have E working on Wayland on FreeBSD. I have managed to build E + EFL with Wayland support but some Linux stuff needs to be added. This is an ongoing work in progress already :-)

In D12217#233878, @vtorri wrote:

@cederom what is the status of that diff ?

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

Mystery solved by @raster and @vtorri =) No patch needed here, just a proper build configuration parameters. Thank you everyone! :-)

Thank you @vtorri :-)

In D12217#233854, @vtorri wrote:

btw, replace -Dopengl=full with -Dopengl=es-egl

Sure thing :-) Maybe engine_gl_drm is some sort of Linux assumption not defined with find_package() or something like this (I was this recently in different software that I am porting). I am a bit multitasked recently, sorry, any hints from someone with bigger knowledge is highly welcome :-) Thanks :-)

When engine_gl_drm is present meson fails with error below and this is the reason I have removed it on FreeBSD. Any better solutions is welcome on how to make this engine_gl_drm known to meson :-)
src/modules/ecore_evas/engines/drm/meson.build:6:2: ERROR: Unknown variable "engine_gl_drm".

Allright, thank you guys, now have a free moment, will try to build with engine_gl_drm added to gl_deps and see how that builds on FreeBSD :-)

Thank you @ProhtMeyhet :-)

Awsome! Now we need to remove elogind direct dependency (on Linux only) and add something that makes EFL/E portable along different platforms (i.e. FreeBSD) using Wayland :-) :-)

@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.

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

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

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

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

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..

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?

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?

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

yyuupp =)

+1 EFL-1.25.1 on FreeBSD-12.2 with libavif-0.8.4 :-(

FAILED: src/modules/evas/image_loaders/libshared_loader_avif.so.p/_usr_ports_devel_efl-1.25.1_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_load_avif.c.o   cc -Isrc/modules/evas/image_loaders/libshared_loader_avif.so.p -Isrc/modules/evas/image_loaders -I../src/modules/evas/image_loaders -I. -I.. -Isrc/lib/evil -I../src/lib/evil -Isrc/lib/eina -I../src/lib/eina -Isrc/lib/eo -I../src/lib/eo -Isrc/lib/efl -I../src/lib/efl -Isrc/lib/emile -I../src/lib/emile -Isrc/lib/eet -I../src/lib/eet -Isrc/lib/eco
re -I../src/lib/ecore -Isrc/lib/eldbus -I../src/lib/eldbus -Isrc/lib/ecore_audio -I../src/lib/ecore_audio -Isrc/lib/ecore_con -I../src/lib/ecore_con -Isrc/lib/ecore_file -I.
./src/lib/ecore_file -Isrc/lib/ecore_input -I../src/lib/ecore_input -Isrc/lib/ecore_x -I../src/lib/ecore_x -Isrc/lib/ecore_win32 -I../src/lib/ecore_win32 -Isrc/lib/ecore_ipc
 -I../src/lib/ecore_ipc -Isrc/lib/ector -I../src/lib/ector -Isrc/lib/evas/software_generic -I../src/lib/evas/software_generic -I../src/modules/evas/engines/software_generic/
filters -Isrc/lib/evas -I../src/lib/evas -Isrc/lib/evas/common -I../src/lib/evas/common -Isrc/lib/evas/include -I../src/lib/evas/include -Isrc/lib/evas/filters -I../src/lib/
evas/filters -Isrc/lib/evas/canvas -I../src/lib/evas/canvas -Isrc/lib/efreet -I../src/lib/efreet -Isrc/lib/ecore_input_evas -I../src/lib/ecore_input_evas -Isrc/modules/evas/
engines/buffer -I../src/modules/evas/engines/buffer -Isrc/lib/ecore_evas -I../src/lib/ecore_evas -Isrc/lib/ecore_imf -I../src/lib/ecore_imf -Isrc/lib/embryo -I../src/lib/emb
ryo -Isrc/lib/eio -I../src/lib/eio -Isrc/lib/ecore_imf_evas -I../src/lib/ecore_imf_evas -Isrc/lib/ephysics -I../src/lib/ephysics -Isrc/lib/edje -I../src/lib/edje -Isrc/lib/e
motion -I../src/lib/emotion -Isrc/lib/ethumb -I../src/lib/ethumb -Isrc/lib/ethumb_client -I../src/lib/ethumb_client -Isrc/lib/elementary -I../src/lib/elementary -Isrc/static
_libs/buildsystem -I../src/static_libs/buildsystem -Isrc/lib -I../src/lib -Isrc/static_libs/libunibreak -I../src/static_libs/libunibreak -Isrc/lib/efl/interfaces -Isrc/lib/e
ctor/gl -Isrc/lib/ector/software -Isrc/lib/evas/gesture -I/usr/local/include/luajit-2.0 -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include/fribidi -I/u
sr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -f
visibility=hidden -Wall -Wpointer-arith -Wunused-parameter -Wsign-compare -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -DEFL_BETA_API_SUPPORT=1 -DELM_IN
TERNAL_API_ARGESFSDFEFC=1 -O2 -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -fPIC -pthread '-DPACKAGE_DATA_DIR="/usr/local/share/evas"' -DNEED_RUN_IN_TREE=1 
-DEFL_BUILD=1 -MD -MQ src/modules/evas/image_loaders/libshared_loader_avif.so.p/_usr_ports_devel_efl-1.25.1_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_lo
ad_avif.c.o -MF src/modules/evas/image_loaders/libshared_loader_avif.so.p/_usr_ports_devel_efl-1.25.1_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_load_avi
f.c.o.d -o src/modules/evas/image_loaders/libshared_loader_avif.so.p/_usr_ports_devel_efl-1.25.1_work_efl-1.25.1_src_modules_evas_image_loaders_avif_evas_image_load_avif.c.o
 -c /usr/ports/devel/efl-1.25.1/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c                                                                   
/usr/ports/devel/efl-1.25.1/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c:68:36: error: too many arguments to function call, expected single arg
ument 'decoder', have 2 arguments                                                                                                                                            
   res = avifDecoderParse(decoder, &raw);                                                                                                                                    
         ~~~~~~~~~~~~~~~~          ^~~~                                                                                                                                      
/usr/local/include/avif/avif.h:741:1: note: 'avifDecoderParse' declared here                                                                                                 
avifResult avifDecoderParse(avifDecoder * decoder);
^                                          
/usr/ports/devel/efl-1.25.1/work/efl-1.25.1/src/modules/evas/image_loaders/avif/evas_image_load_avif.c:155:41: error: too many arguments to function call, expected single ar
gument 'decoder', have 2 arguments         
        res = avifDecoderParse(decoder, &raw);
              ~~~~~~~~~~~~~~~~          ^~~~
/usr/local/include/avif/avif.h:741:1: note: 'avifDecoderParse' declared here
avifResult avifDecoderParse(avifDecoder * decoder);
^                                          
2 errors generated.

Sorry I have the same issue and resize does not help. My screen is scaled. I need to see that Save button anyways. This is still clearly a bug of screenshotter or dialogs that it cannot adapt to screen scaling/magnification that is a standard E feature. This needs fix please :-)

Hello @raster :-) If creating a dedicated group of keys and key bindins to filter that would work on a lock screen then fine, no specific difference for me, except we have multimedia keys (Vol+, Vol-. Mute, Play, Pause, Next, Previous, etc) on that list by default.. that should give the multimedia controls available on the lock screen by default :-)

Thanks @ProhtMeyhet but the support should work out of the box with no additional configuration and/or lockscreen gadgets :-)

Awsome! Thank you! =)

Thank you for adding crop and edit functions in current E. The only more thing missing is CLIPBOARD - I need to share picture to E then open in a browser then copy paste it..

Thank you @stefan_schmidt please go ahead and push this way thank you for your time and checking out :-)

Thank you @Peter2121.. I had to modify one header that was linux specific in order to make VNC server work:

I can confirm that this is the EFL build time configuration issue. Older EFL build works fine with Terminology 1.7.0. I will looks into that epoll stuff in a free moment. Thank you!! :-)

Thank you for your feedback that it works for you, this is valuable input.

The problem with Terminology 1.7.0 is not fixed, exactly the same setup and 1.6.0 works fine, I cannot remove libepoll-shim from system because other applications depend on it. Will report a working solution if I find one. Thanks for your quick response :-)

Well, it looks like I am updating the port, because no one did that so far ;-)

In T8716#152440, @netstar wrote:

@cederom

https://www.enlightenment.org/docs/distros/freebsd-start.md

These goes the port updates tickets and whole ports sources / patches are there too:

• Terminology: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245598
• EFL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245594
• Enlightenment: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245596

Hey @netstar :-) Which version of Terminology on which E and EFL?

Sure thing, I am porting EFL+E to FreeBSD so no problem with building and patching :-)

Hello @billiob and thank you for quick response :-)

EFL builds fine now with new Wayland, thank you! Need to tune some stuff on Enlightenment side to make it work with Wayland. Will send updates when ready! :-)

Just to be clear - EFL builds fine with wl-obsolete enabled.. but the new Enlightenment requires wl2 (ecore_wl2 that is provided with wl build switch) - I have question is there any reason to use wl-obsolete and would that allow running Enlightenment on Wayland? I did not manage to do it and this is why I am focusing on wl / ecore_wl2 at the moment :-)

Regarding there "linuxism" includes and DMA stuff there is Greg V that knows the stuff and below is his response. On the other hand @netstar I simply commented out the includes and code with linux stuff and EFL build successfully. That may indicate we are one step from running WL2 on FreeBSD :-)

Thank you :-) Is there any reference / wiki on how to run E on Wayland? This seems a hot topic right now :-)

That is soo cool @devilhorns thank you for your feedback and support! I may take this part with support from the FreeBSD team.. in my free time.. which is a bit short until 202008.. but the new version is already working on my machine using X11 so step by step we can do that :-)

Hello and thank you for quick response :-)

Hello @Peter2121 and thank you for the hint! I also observed this efreetd problem and I am more than happy that it is resolved by now :-)

I am working on EFL (1.20.7 ->1.23.3) and Enlightenment (0.22.4 -> 0.23.1) upgrade on FreeBSD. Problem is fixed in new release. Things are almost ready and will show up soon :-)

The same here EFL 1.23.3 on FreeBSD. I am building on a system that runs EFL 1.20.7 already that I want to update..

one constant error that shows up at the console tells to: eina_btlog << EOF EOF.
sometimes it tells the resource is null os nonexistent. dont have it right now. maybe will try to catch and upload here so you have more detailed information..

not really :-( some issues that i have noticed:

1. ui hangs but mouse moves. sometimes after several minutes things get back to normal sometimes not.
2. window switcher / selector is buggy. almost always with virtualbos running it cannot switch back to other windows and does not show windows on the list while switching with Ctrl+Tab. this is critical as i have to restart session and interrupt my work.

Thank you Peter! Enlightenment really rox! Just as my beloved FreeBSD! This is something really really new and the design is simply amazing.. really reminds me of the old good Unix or even Amiga times! :-)

How can I track down the problem?