Nice catch, thanks!

Minor nit above, nothing important.

Approved with my comment above.

LGTM

LGTM

In D23856#524763, @kevans wrote:

We could maybe MFC posix_fallocate support for shmfd, but it'd be a little contorted because we can't change struct fileops like we did in head. memfd_create could be MFC'd, but file sealing cannot and I'm not sure we want it if file sealing cannot be supported.

In D23856#524669, @jbeich wrote:

In D23856#524657, @zeising wrote:

This is a bug (or missing feature) in FreeBSD 12 that posix_fallocate() doesn't work with shm_open()?

Missing feature but using posix_fallocate with shm_open is unusual compared to memfd_create.

Should we poke @kevans about merging that change to FreeBSD 12 if possible?

Existing -RELEASE that haven't reached EOL still need to be supported in ports/. Backporting memfd_create would be more useful but maybe more risky.

Would this affect xorg-server as well?
I believe you have to make the UPDATING more verbose, to explain to people more about the change. They might not be aware of libxkbcommon, or which of xf86-input-libinput and xf86-input-keyboard they use. Perhaps you can add part of pkg-message also to updating?

I also wonder if we have the same pattern of shm_open() posix_fallocate() in other places (mesa comes to mind). I haven't looked though.

Can you please explain this to me a bit more, please?
This is a bug (or missing feature) in FreeBSD 12 that posix_fallocate() doesn't work with shm_open()? Should we poke @kevans about merging that change to FreeBSD 12 if possible?
I believe that the code will call os_resize_anonyous_file(), which call posix_fallocate(), even with the call to memfd_create(), if this works on FreeBSD 13, perhaps the patch should be made conditional on that version anyway? Or am I misreading the wayland code?
Apologies for all the question, I'm just a bit confused trying to understand it all.
Thank you for debugging this!

Have you checked that downstream consumers are ok with the static library disappearing?
Once that's done, this is OK.

Approved.
Please leave the FIXDRM option off for now, we might want to enable it in the future, but would like some more time to figure out what's going on.
There is no need to bump portrevision I think, since the default package stays the same.

LGTM, please land together with https://reviews.freebsd.org/D23696 and if possible https://reviews.freebsd.org/D23801 .

LGTM

Update patch to remove BROKEN=

LGTM, I'll leave it to you to decide on committing it now, or holding for D23696.

I believe a portrevision bump of wayland is warranted, since it changes the code wayland is compiled with.

I'd like to wait for https://reviews.freebsd.org/D23696, since you state yourself that you work around the issue in a quite hackis way, and this way we don't have to bump wayland version twice.
This patch is also missing portrevision bump, which is needed since you change dependencies.

Idea is to merge it to v4.16 and then pick it into 5.0.

I just made a PR for this in the drm-kms repo, can you please have a look in case I screwed something up.
https://github.com/FreeBSDDesktop/kms-drm/pull/219

In D23764#522191, @manu wrote:

In D23764#522176, @hselasky wrote:

You need to bump the __FreeBSD_version to xxx80, because the following change is needed in drm-kms: @zeising Please ack!
@manu : This change should not be MFC'ed for now.

From c2faeead8478457b465617bf0edde2ad72558469 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky <hps@selasky.org>
Date: Thu, 20 Feb 2020 12:03:04 +0100
Subject: [PATCH] Update code after header file change in -current.
Signed-off-by: Hans Petter Selasky <hps@selasky.org>
---
 linuxkpi/dummy/include/linux/shmem_fs.h | 0
 linuxkpi/gplv2/include/linux/shmem_fs.h | 3 +++
 2 files changed, 3 insertions(+)
 delete mode 100644 linuxkpi/dummy/include/linux/shmem_fs.h
 create mode 100644 linuxkpi/gplv2/include/linux/shmem_fs.h
diff --git a/linuxkpi/dummy/include/linux/shmem_fs.h b/linuxkpi/dummy/include/linux/shmem_fs.h
deleted file mode 100644
index e69de29bb..000000000
diff --git a/linuxkpi/gplv2/include/linux/shmem_fs.h b/linuxkpi/gplv2/include/linux/shmem_fs.h
new file mode 100644
index 000000000..37bfb6797
--- /dev/null
+++ b/linuxkpi/gplv2/include/linux/shmem_fs.h
@@ -0,0 +1,3 @@
+#if __FreeBSD_version >= 1300080
+#include_next <linux/shmem_fs.h>
+#endif
-- 
2.25.0

Thanks,
Can you submit this patch to the v5.0 branch of kms-drm ? There is another PR to merge so doing a new release with both would save time.

I've seen this, I'll fix the drm drivers and update tonight.

This has been committed, but I made a mistake in the commit log so it wasn't picked up properly. Close this.

Are the meson patches submitted upstream?

https://gitlab.freedesktop.org/wayland/wayland/merge_requests/61
Here is a link to the upstream pull request and discussion, it's also linked in the Makefile, but put it here as well.

There are comments on the suggested patches upstream. Until those are resolved, this is not approved.

Where did the static libraries go?
I don't know if they are used, but an exp-run might be warranted if we remove them from the package.

I'm not a fan of ripping out that commit, I rather we wait for https://github.com/jiixyj/epoll-shim/issues/15, but go ahead, we can fix that later.

In D23643#519404, @greg_unrelenting.technology wrote:

Yep, wayfire consumes 100% CPU for me. Here's a flamegraph, probably should've used pmcstat instead of dtrace but timerfd_settime looks like a place to look. Looks like the kqueue fast path is not being used, but either way this shouldn't happen..

I have no problems with this change from an x11 perspective. However, please give @hselasky the chance to chime in, since he knows much more about the lkpi than I do.