Page MenuHomePhabricator

EFL-1.23.3: Hardcoding Linux DMA in EFL breaks build for Wayland on FreeBSD
Closed, ResolvedPublic


src/lib/ecore_wl2/ecore_wl2_buffer.c contains hardcoded linux DMA code that prevents building Wayland support on FreeBSD. Please use more generic approach that does not break portability :-(

cederom created this task.Apr 19 2020, 5:45 PM

Can you be more specific about what is causing the building to fail ? I don't have access to FreeBSD, so any extra info you can provide to help isolate where exactly the build is breaking would be a great help !!


Can you please specify your build arguments to build EFL with wayland support on FreeBSD?

E requires ecore_wl2. How did you build EFL?

Hello and thank you for quick response :-)

We are updating ELF port from 1.20.7 to 1.23.3 and Enlightenment from 0.22.4 to 0.23.1. The work is noted in a link below.

It looks like this "linux hardcode" is a part of DRM KMS specification, I am not really familiar with that and I was a bit surprised by that "linux" name hardcode, I have some local support and it looks like we should have that included in FreeBSD's DRM implementation. I will verify that and will report back.. work in progress :-)

This is also an effort to run Wayland on FreeBSD and I would really love to see Enlightenment running as the first fully featured WM on my favorite OS :-)

@cederom I'm glad to see people are porting to *bsd. With regard to eeze using udev (and thus not portable), if someone would like to submit patches to make eeze use whatever *bsd uses for devices, then that would be great !! In all honesty, the *bsd port should not really use deprecated ecore_wl, ecore_drm libraries. Those are terribly old, have a few flaws, are unmaintained, and have since been replaced w/ ecore_wl2 & ecore_drm2. Also, if someone would like to provide patches for ecore_wl2 to support *bsd, please don't hesitate to submit them.

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

EFL 1.23.3 and E 0.23.1 fixes screen freeze bug that was critical and blocker for my work. I know that 0.24 is coming up soon with efreetd fixes and once we have 0.23.1 port ready with new meson build ready it should be fairly easy to get newer versions :-)

FreeBSD use DEVD in place of UDEV. I am sure we can find a working solution :-)

So far I am working on ecore_wl2 in order to get E+EFL working on Wayland :-)

@cederom Well, the work on ecore_wl2 porting would be good for EFL wayland Client apps (ie: running Terminology in Weston, etc). The work of fixing eeze to use DEVD would be needed for running the Enlightenment Wayland compositor.

cederom added a comment.EditedApr 21 2020, 9:47 AM

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

So far we use those disables in order to build and run on FreeBSD and that seems current TODO list right after Wayland:

meson -Deeze=false -Dv4l2=false -Dfb=false -Ddrm=false -Dwl=true -Dsystemd=false build

Build EFL

../src/lib/ecore_wl2/ecore_wl2_buffer.c:20:10: fatal error: 'linux/dma-buf.h' file not found
#include <linux/dma-buf.h>

Do this horrible thing

--- a/src/lib/ecore_wl2/ecore_wl2_buffer.c
+++ b/src/lib/ecore_wl2/ecore_wl2_buffer.c
@@ -17,7 +17,25 @@
 #include <sys/mman.h>
 #include <sys/ioctl.h>
+#if defined(__linux__)
 #include <linux/dma-buf.h>
+#elif defined(__FreeBSD__)
+/* begin/end dma-buf functions used for userspace mmap. */  
+struct dma_buf_sync {
+        __u64 flags;
+#define DMA_BUF_SYNC_READ      (1 << 0)
+#define DMA_BUF_SYNC_WRITE     (2 << 0)
+#define DMA_BUF_SYNC_START     (0 << 2)
+#define DMA_BUF_SYNC_END       (1 << 2)
+#define DMA_BUF_BASE            'b'
+#define DMA_BUF_IOCTL_SYNC      _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)

Then if you link against -lepoll-shim EFL WILL build but it's not going to work anywhere. I'm not sure these macros even translate.

There is no current weston port. E won't build. As well as the repurcussions from the EFL build options requred.

I'd say FreeBSD porter shouldn't be enabling wayland support.

@cederom on Linux there are guides in the "docs" section on As far as FreeBSD is concerned, it might be some time yet.

cederom added a comment.EditedApr 21 2020, 9:59 AM

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

On Mon, Apr 20, 2020 at 11:59 AM Greg V <> wrote:
> Apr 20, 2020 4:39:15 AM Tomasz CEDRO <>:
> Enlightenment has and needs new Wayland support that is based on
> ecore_wl2 from EFL. Someone hardcoded Linux DMA code into
> src/lib/ecore_wl2/ecore_wl2_buffer.c and that part of EFL does not
> build anymore on FreeBSD (not mandatory to run on Xorg). The good news
> is that EFL builds with both old Wayland support (wl-deprecated
> switch) and new one required for Enlightenment (wl switch) when all
> linuxisms are commented out from ecore_wl2_buffer.c. This means if we
> find a FreeBSD specific replacement for those DMA transfers all should
> work fine..?

There are no "Linux specific DMA transfers" in userspace applications :) DMA-BUF is basically a way to refer to GPU buffers from userspace, pass them around as file descriptors, and synchronize access to them. Of course it is supported, it's a very important part of the DRM stack.

Nothing currently installs the uapi header <linux/dma-buf.h> that contains some definitions for the sync ioctl, but the ioctl works:

Chromium currently patches ifdefs to use the inlined copy of the header that's already there for older Linux installations:

But really we need a tiny port that installs that header already :)

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

@cederom I see Zero good reason to use obsolete wl code .. In fact, I highly discourage it's usage, so much to the point that I deprecated those libraries a while ago ;) In theory, it may be possible to use obsolete in order to run E-WL ... but I cannot speak for it's actual usefulness. YMMV of course, but as I am sitting here writing this, I cannot help but shake my head and scream NO! Don't do it....

Fixed in 53044bf10749ce5456df6cf1398834fc9ab3de84

Needs LOTS of work from @devilhorns

Thanks for report @cederom .Not working yet. Hopefully not too far away (in months or years).

@netstar Just to clarify ... what work is needed here from me ??

None any more.

In the future I would imagine heaps of work. I think what raster said, about waiting for others in BSD communities to get things up-to-speed makes sense.

@netstar Ahh ok :) I just wanted to double check that there was nothing you needed me to do for this ticket. Thanks for the patch btw :) Yes, in the future if there is anything that the *bsd* people require from me, please let me know.

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