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%2B0xAQDu7RQOtN-rbSH2qxf4f6t=UrOCDvHkScurw@mail.gmail.com> In-Reply-To: <e775e058-5904-402f-a505-6775e318bda0@localhost> References: <CAFYkXjmfyLZAi1HZe-RE3wLxa6GRNP6GkmtZG-4T2puRDOz0JA@mail.gmail.com> <CAFYkXjkFT7R0A-ZsH4p6C0_h8%2BqJ0-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, ¶ms_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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFYkXjkqFO%2B0xAQDu7RQOtN-rbSH2qxf4f6t=UrOCDvHkScurw>