wpewebkit: update to 2.54.0, drop legacy WPE

[dangowrt]

📦 Package Details

Maintainer: @dangowrt

Description:

Update WPEWebKit to 2.54.0 and move the feed to a WPEPlatform-only build, retiring the libwpe legacy API and the packages that existed only to serve it. This supersedes the previous contents of this PR (the 2.52.6 point-release update), retargeted to 2.54.0 and rebased onto current master.

ENABLE_WPE_LEGACY_API=OFF builds WPEWebKit against WPEPlatform alone. WPE::libwpe is linked only under that option, Tools/wpe/backends (the wpebackend-fdo consumer) is only added when it is on, and the generated wpe-webkit-2.0.pc emits Requires: ... wpe-1.0 from the same guard. With it off, libwpe and wpebackend-fdo have no remaining consumer, and cog was the only other package using them. MiniBrowser covers the testing role and links neither.

Two dependency adjustments are required by 2.54. libatomic is new because libWPEWebKit-2.0.so now pulls __atomic_load_16, __atomic_store_16 and __atomic_compare_exchange_16, which are not inlined on x86_64 without -mcx16. libstdcpp and libxkbcommon used to arrive transitively through libwpe; WPEPlatform links XkbCommon::XkbCommon directly and libstdc++ is a direct NEEDED of the library, the injected bundle and all three helper processes.

On the patch series: 122 applies in reverse against 2.54 and is dropped as upstream; 126 keeps only its DWARF register-mapping hunk, upstream having taken the other three. Patches 138 and 147 are ported rather than refreshed, because upstream hoisted the 63 inline atomic op bodies out of atomicLoadOp(...)/ipintOp(...) into 63 named do*Atomic* macros; the mapping was verified rather than assumed, deriving the expected slow-path helper from each macro name reproduces the helper named in the corresponding hunk for all 63. While porting, 147's compare-exchange slow path was found to issue cCall4 while assigning only a1 and a3, never a2, so the helper received an uninitialised expected argument, and the result in r0 was never moved back; both are fixed across all seven cmpxchg macros.

Six patches are new. LOG_CHANNEL(WebDriverClassic) is read unguarded in WebDriverService::handleRequest() while Source/WebDriver/Logging.h only declares the channels under #if !LOG_DISABLED || !RELEASE_LOG_DISABLED; a release build with assertions off and no journald, OS_LOG or Android backend disables both and fails to compile.

Two are RISCV64 offlineasm gaps of the same shape, both found by CI. emitCall accepts only RegisterID and LabelReference, so call .continue in LowLevelInterpreter.asm aborts LLIntAssembly.h generation with "Unable to match operands [LocalLabelReference]", while emitJump immediately above already treats both label kinds alike. Then riscv64LowerFPBranch accepts only a LocalLabelReference, so a floating-point branch to a global label fails with "Unable to match operands [FPRegisterID, FPRegisterID, LabelReference]"; it lowers to the zero-compare branches, whose renderer has the same restriction, whereas the two-register branch renderer beside it already accepts both.

One is for 32-bit x86, also found by CI. libpas selects a __uint128_t for pas_pair wherever the compiler is not Clang and the target is not 32-bit ARM, which leaves 32-bit x86 without a type; keying the structure fallback on !defined(__SIZEOF_INT128__) covers every such target instead of enumerating architectures. The pair atomics need the same condition, because pas_compare_and_swap_pair_weak and its four siblings pass pas_pair to __atomic_*_n, which takes a scalar. 32-bit ARM already answers that with an unreachable stub, and nothing calls those functions on such a target since BENABLE_LIBPAS requires BCPU(ADDRESS64).

Those three reproduce identically on 2.52.3, so they are long-standing rather than regressions introduced by this update.

The next is specific to 2.54, which introduces precompiled headers (2.52's WebKitMacros.cmake had no PCH machinery at all) and so compiles the WebKit prefix header as a translation unit of its own for the first time. WebCore stages its private headers as a flat directory of symlinks into the source tree, so a WebCore header reached from WebKit resolves its siblings by bare name against the directory it really lives in: WebKitPrefix.h reaches GStreamerCommon.h via SharedBuffer.h, and that includes "GraphicsTypesGL.h", which sits one level up in platform/graphics where nothing on WebKit's include path reaches it. Adding the flat private header directory to WebKit_PRIVATE_INCLUDE_DIRECTORIES resolves it. It is added last deliberately: WebKit carries its own headers with names WebCore also uses, WebGPUSupportedFeatures.h among them, and placing the directory earlier shadows them and breaks the GPUProcess build with incomplete WebKit::WebGPU types.

Removing wpebackend-fdo drops @mirko's stale-buffer fix along with the package it fixes. That fix is in wpebackend-fdo's own src/ws-shm.cpp and src/ws-egl.cpp, not in cog; cog's drm renderer copy loop was only where the symptom appeared. It has no counterpart under WPEPlatform, whose Wayland support is a plain Wayland client with no wayland-server, wl_shm_buffer, surfaceCommit or exportShmBuffer anywhere, so there is no equivalent site to carry it to.

prefers-reduced-motion is inverted on WPE: SystemSettingsManagerProxy::reducedMotion() negates WPE_SETTING_REDUCED_MOTION, which is documented and registered as defaulting to false, so the default reports that the user prefers reduced motion and every site honouring the media query disables its animations. The negation is left over from enableAnimations(), which this function replaced in WebKit/WebKit@446267f, where it was correct because the value read was the opposite setting WPE_SETTING_DISABLE_ANIMATIONS. Still present in WebKit main and unreported upstream at the time of writing; being filed at bugs.webkit.org separately. This is a 2.54-series regression, since neither the function nor the setting exists in 2.52.x.

A test-version.sh override is added for the generic package tests. Nothing these packages install reports the package version: the three programs in libwpewebkit are helper processes the library spawns and take no arguments, WPEWebDriver has no --version, and wpe-webkit-2.0.pc belongs to Build/InstallDev and is not shipped. The override checks that each subpackage installed the artefacts it should, which is what the probe was standing in for.

Link: https://wpewebkit.org/release/wpewebkit-2.54.0.html

---

🧪 Run Testing Details

• OpenWrt Version: main
• OpenWrt Target/Subtarget: x86/64
• OpenWrt Device: qemu (build-tested only, not yet run-tested on hardware)

libwpewebkit, wpewebkit-driver and wpewebkit-minibrowser all compile and package for x86_64/musl with no unresolved library dependencies, and the whole series applies with git am onto a pristine 2.54.0 tree. The riscv64 and i386 fixes are derived from the CI logs of the previous run and have not been built on those targets locally.

On the CI results themselves: arm_cortex-a9 completed a full build in 5h26m, so the work does fit inside the runner limit, but aarch64_generic and arm_cortex-a15 are cancelled at 6h. That boundary moves with runner load and with how long the Mesa and LLVM builds take, host and target, so those two are expected to flip either way between runs rather than indicating a defect. The mips, mipsel and powerpc jobs pass quickly because the architecture is outside this package's DEPENDS.

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/wpewebkit/refresh V=s

• It is structured in a way that it is potentially upstreamable