Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Apr 2020 21:25:16 +0200
From:      Tomasz CEDRO <tomek@cedro.info>
To:        Greg V <greg@unrelenting.technology>
Cc:        FreeBSD Questions Mailing List <freebsd-questions@freebsd.org>, freebsd-x11@freebsd.org
Subject:   Re: Wayland on FreeBSD
Message-ID:  <CAFYkXjkqFO+0xAQDu7RQOtN-rbSH2qxf4f6t=UrOCDvHkScurw@mail.gmail.com>
In-Reply-To: <e775e058-5904-402f-a505-6775e318bda0@localhost>
References:  <CAFYkXjmfyLZAi1HZe-RE3wLxa6GRNP6GkmtZG-4T2puRDOz0JA@mail.gmail.com> <CAFYkXjkFT7R0A-ZsH4p6C0_h8+qJ0-wWJ--tTJLtS0Pja0ZzSQ@mail.gmail.com> <e775e058-5904-402f-a505-6775e318bda0@localhost>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Mon, Apr 20, 2020 at 11:59 AM Greg V wrote:
> There are no "Linux specific DMA transfers" in userspace applications :) =
DMA-BUF is basically a way to refer to GPU buffers from userspace, pass the=
m around as file descriptors, and synchronize access to them. Of course it =
is supported, it's a very important part of the DRM stack.

Hmm, is it then normal to use on non-Linux code like this?

#include <linux/dma-buf.h>
#include "linux-dmabuf-unstable-v1-client-protocol.h"

struct zwp_linux_dmabuf_v1 *dmabuf;
struct zwp_linux_buffer_params_v1 *dp;

dmabuf =3D ecore_wl2_display_dmabuf_get(ewd);
dp =3D zwp_linux_dmabuf_v1_create_params(dmabuf);
zwp_linux_buffer_params_v1_add(dp, db->fd, 0, 0, db->stride, 0, 0);
buf =3D zwp_linux_buffer_params_v1_create_immed(dp, db->w, db->h,
format, flags);
wl_buffer_add_listener(buf, &buffer_listener, db);
zwp_linux_buffer_params_v1_destroy(dp);

static void
_create_succeeded(void *data EINA_UNUSED,
struct zwp_linux_buffer_params_v1 *params,
struct wl_buffer *new_buffer)
{
wl_buffer_destroy(new_buffer);
zwp_linux_buffer_params_v1_destroy(params);
}

zwp_linux_buffer_params_v1_destroy(params);
struct zwp_linux_buffer_params_v1 *dp;

dp =3D zwp_linux_dmabuf_v1_create_params(ewd->wl.dmabuf);
zwp_linux_buffer_params_v1_add(dp, buf->fd, 0, 0, buf->stride, 0, 0);
zwp_linux_buffer_params_v1_add_listener(dp, &params_listener, ewd);
zwp_linux_buffer_params_v1_create(dp, buf->w, buf->h,
DRM_FORMAT_ARGB8888, 0);

Is this some sort of Linux KMS/DRM specification that keeps explict
"linux" name hardcoded and we have them too on FreeBSD named that way?
Never seen anything like this :-)


> Nothing currently installs the uapi header <linux/dma-buf.h> that contain=
s some definitions for the sync ioctl, but the ioctl works:
> https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.16/linuxkpi/gplv2/s=
rc/linux_dmabuf.c
>
> Chromium currently patches ifdefs to use the inlined copy of the header t=
hat's already there for older Linux installations:
> https://github.com/freebsd/freebsd-ports/blob/master/www/chromium/files/p=
atch-ui_gfx_linux_client__native__pixmap__dmabuf.cc
> https://chromium.googlesource.com/chromium/src/+/refs/tags/84.0.4120.1/ui=
/gfx/linux/client_native_pixmap_dmabuf.cc
>
> But really we need a tiny port that installs that header already :)

Will look into this in a free moment and report back! Does this mean
we only put that header and things start workin? ;-)

Thank you Greg!! :-)

--=20
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?CAFYkXjkqFO+0xAQDu7RQOtN-rbSH2qxf4f6t=UrOCDvHkScurw>