- User Since
- Apr 12 2019, 9:42 AM (93 w, 3 d)
Mon, Jan 18
Thank you @vtorri :-) Can anyone please tell why OpenGL-ES is a hard dependency for DRM/Wayland? Why we cannot use full OpenGL? :-)
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 :-)
Sun, Jan 17
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".
Thu, Jan 14
Allright, thank you guys, now have a free moment, will try to build with gl_deps in place of engine_gl_drm and see how that builds on FreeBSD :-)
Dec 18 2020
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  is seems that LIBSEAT would be better ELOGIND replacement rather than using whole wlroots :-)
After discussion on WLROOTS GitHub  is seems that LIBSEAT would be better ELOGIND replacement rather than using whole wlroots :-)
Dec 17 2020
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..
Dec 16 2020
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  :-)
I have created a separate report for DRM enforcing EEZE although this EEZE is explicitly disabled with meson switch: https://phab.enlightenment.org/T8867
Dec 15 2020
Dec 14 2020
+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.
Nov 28 2020
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 :-)
Oct 19 2020
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 :-)
Oct 8 2020
Thanks @ProhtMeyhet but the support should work out of the box with no additional configuration and/or lockscreen gadgets :-)
Sep 22 2020
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..
Jun 12 2020
Thank you @stefan_schmidt please go ahead and push this way thank you for your time and checking out :-)
May 15 2020
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!! :-)
May 14 2020
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 ;-)
These goes the port updates tickets and whole ports sources / patches are there too:
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! :-)
May 13 2020
May 3 2020
Apr 21 2020
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 :-)
Apr 20 2020
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 :-)
Apr 19 2020
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 :-)
Apr 17 2020
Apr 9 2020
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..
Aug 7 2019
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:
- ui hangs but mouse moves. sometimes after several minutes things get back to normal sometimes not.
- 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.
Apr 15 2019
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?