graphics/wayland: Update to 1.18

[jbeich]

Summary

ABI is compatible. Other changes:

• Allow memfd_create on FreeBSD 13 for sealing
• Drop ms_timeout workaround in favor of upstream fix
• Drop posix_fallocate patch as it was disabled in rP455878
• Adjust posix_fallocate comment for more clarity
• Temporarily revert event loop update until epoll-shim#15 is fixed

Test Plan

Builds fine on:

• 11.3 aarch64
• 11.3 amd64
• 11.3 armv6
• 11.3 i386
• 12.0 amd64
• 12.0 i386
• 12.1 aarch64
• 12.1 amd64
• 12.1 armv6
• 12.1 armv7
• 12.1 i386
• 13.0 amd64
• 13.0 i386
• Base GCC 4.2.1 (mimics powerpc*, mips*, riscv64)

Works fine on:

• multimedia/libva-intel-driver
• multimedia/mpv
• www/firefox + MOZ_ENABLE_WAYLAND
• x11-servers/xwayland-devel
• x11-wm/cage
• x11-wm/sway
• x11/wl-clipboard

[jbeich]

• Update TIMESTAMP in distinfo
• Adjust commit message for review URL

[imp]

this looks promising...

One concern, though, is the sway using 100% of the CPU considered a show stopper? It sounds quite serious...

[jbeich]

• Refresh unchanged patches to avoid confusion from context lines changes in D23644

In D23643#519264, @imp wrote:

One concern, though, is the sway using 100% of the CPU considered a show stopper? It sounds quite serious...

Only if someone can reproduce. Upstream commit is easy to revert (for now). Debugging this is outside of my domain i.e., not familar with the APIs used.

[val_packett.cool]

1.17.0-60-g60a8d29

libwayland now uses only one file descriptor to keep track of all the timer event sources

Ha, and we've had to improve epoll-shim for the old way.. https://github.com/jiixyj/epoll-shim/issues/8

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..

Created issue: https://github.com/jiixyj/epoll-shim/issues/15

[zeising]

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..

Sounds like this at least warrants some investigating before merging this. @greg_unrelenting.technology , sounds like you've started looking into this, any chance you can spend some more time digging into it?
Thanks!

[val_packett.cool]

In D23643#519412, @zeising wrote:

sounds like you've started looking into this, any chance you can spend some more time digging into it?

I am looking. For now we can just revert that change and commit.

[jbeich]

• Revert regressing change to unblock progress, as suggested by Greg

Now it's ready to land (without D23644). I've actually been dogfooding the revert since yesterday without issues.

[manu]

LGTM
I've started a build to test on my laptops later today.
ping @zeising for x11 approval.

[zeising]

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.

[manu]

Build finished, tested ok with sway so I think we're good to go.

[jbeich]

@zeising, epoll-shim fix may have increased risk if something wasn't covered by tests. Seemed like a recipe to unnecessarily delay libwayland update for one bugfix that doesn't affect API/ABI. If devel/libepoll-shim is aggressively updated then any risk would be short-lived.

Now that @bapt landed this change we can take time to test epoll-shim fix.