Page MenuHomeFreeBSD

graphics/wayland: Update to 1.18
ClosedPublic

Authored by jbeich on Feb 12 2020, 11:52 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Mar 11, 3:02 PM
Unknown Object (File)
Feb 20 2024, 7:36 AM
Unknown Object (File)
Feb 20 2024, 7:36 AM
Unknown Object (File)
Feb 20 2024, 7:36 AM
Unknown Object (File)
Feb 20 2024, 7:36 AM
Unknown Object (File)
Feb 20 2024, 7:36 AM
Unknown Object (File)
Feb 20 2024, 7:36 AM
Unknown Object (File)
Feb 20 2024, 7:22 AM
Subscribers

Details

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

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

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

this looks promising...

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

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

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

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!

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 edited the summary of this revision. (Show Details)
  • 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.

jbeich edited the summary of this revision. (Show Details)
jbeich edited the summary of this revision. (Show Details)
manu added a subscriber: manu.

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

This revision is now accepted and ready to land.Feb 14 2020, 9:09 AM

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.

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

This revision was automatically updated to reflect the committed changes.

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