qt5base: fix dependencies and improve packaging resilience

[titobrasolin]

This update strengthens the qt5base package for diverse architectures:

• Add +libatomic to core dependencies to prevent linking errors.
• Add +libdrm to linuxfb and eglfs platform plugins.
• Add @PACKAGE_qt5base-input-autodiscovery to libinput plugin dependencies.
• Introduce wildcard checks in installation macros to prevent 'cannot stat' errors when specific plugins are disabled by the Qt configuration.
• Fix --qpa configuration logic in Build/Configure.
• Clean up and refresh existing patches, removing the obsolete 200-header-dep-fix.patch.

Fixes: #73
Fixes: #74
Fixes: #104

[mirko]

Just double checking: libdrm is now unconditionally considered a dependency, because we do not (want to) support the legacy-framebuffer interface anymore, correct?

[titobrasolin]

Dug into the qtbase 5.15.16 sources to get a definitive answer instead of guessing.

It's not a deliberate move away from legacy fbdev — linuxfb's plain, non-DRM fbdev path (qlinuxfbscreen.cpp) is untouched and still the default rendering path. The libdrm dependency comes from Qt5 itself:

• src/plugins/platforms/linuxfb/linuxfb.pro#L20-L24 conditionally compiles in an additional DRM-accelerated screen backend (qlinuxfbdrmscreen.cpp) alongside the plain fbdev one, whenever kms_support-private is available — it's baked into the same libqlinuxfb.so.
• src/platformsupport/kmsconvenience/kmsconvenience.pro#L15 — the kms_support module — is a static internal module with QMAKE_USE += drm.
• It only gets built when qtConfig(kms) is true (src/platformsupport/platformsupport.pro#L28-L29), and that feature is itself gated on libs.drm in src/gui/configure.json#L1276-L1279.

We configure with --kms=$(if $(CONFIG_BUILD_qt5base-gui_DRM),yes,no), and BUILD_qt5base-gui_DRM defaults to y. So with the default config, the DRM linkage ends up baked into libqlinuxfb.so's NEEDED list regardless of which fbdev mode a board actually uses at runtime — same class of issue as the libatomic case in #74, just Qt-internal this time rather than toolchain-internal.

Given that, unconditional +libdrm is correct as long as BUILD_qt5base-gui_DRM defaults to y — but it's more precise to tie it to that same symbol instead of leaving it always-on:

-  DEPENDS+=+qt5base-core +qt5base-gui +libfreetype +libdrm +PACKAGE_qt5base-input-autodiscovery:libudev +PACKAGE_qt5base-plugin-input-libinput:libinput
+  DEPENDS+=+qt5base-core +qt5base-gui +libfreetype +BUILD_qt5base-gui_DRM:libdrm +PACKAGE_qt5base-input-autodiscovery:libudev +PACKAGE_qt5base-plugin-input-libinput:libinput

so a build that explicitly disables DRM support won't carry it either.

I'd like to look further into the other points raised in this PR before amending the commit and updating it, so I'll hold off pushing until I've gone through those as well.

[mirko]

This feels kind of odd - why would libinput support depend on the input-discovery package being present?

[titobrasolin]

Hi Mirko, thanks for the feedback!

I added this dependency because, as far as I can tell, Qt5's libinput support has a strict pre-condition requiring libudev to be detected during configure.

Since udev is currently hard-disabled in this Makefile (see lines 35-36):

# hard disable udev support for now
CONFIG_PACKAGE_qt5base-input-autodiscovery:=

It seems that libinput fails to meet its requirements. In fact, a CI test I ran without the @PACKAGE_qt5base-input-autodiscovery constraint consistently fails with:

ERROR: Feature 'libinput' was enabled, but the pre-condition 'features.libudev && libs.libinput' failed.

I used the @ dependency as a sort of safety switch to keep the build green, but I'd be happy to hear your thoughts on a better way to handle these implicit Qt5 requirements!

[mirko]

All info I can gather around this "hard disable" for now is this:

• 10cefd1
• https://qt-project.atlassian.net/browse/QTBUG-86630

While it was both me creating the commit and the Qt-ticket, I don't recall the details anymore, other than "behaviour changed".

As a matter of fact, I never saw the reason for using libinput anyway.
evdev works fine with /dev/event* devices.
Maybe just purging the libinput-support/-package for good?

[titobrasolin]

Thanks for the feedback, Mirko — and sorry for the slow follow-up.

Looking into it a bit more: libinput's device discovery relies on udev's ID_INPUT_* tagging to classify devices (keyboard, mouse, touchpad, etc.) — it doesn't have another mechanism for that. So as long as qt5base-input-autodiscovery (udev) stays disabled here, a libinput plugin wouldn't really have a working discovery path regardless of how the configure precondition is handled.

Given that, the @PACKAGE_qt5base-input-autodiscovery:libinput dependency seems correct as a reflection of an actual (currently unmet) requirement, rather than an arbitrary workaround. I'd keep it as-is for this PR, and treat a possible removal of libinput in favor of evdev as a separate follow-up issue/PR, so it doesn't hold up #73/#74/#104. Happy to open that follow-up if it sounds reasonable to you.

[mirko]

This feels like a huge pitfall and debug hell, where the build completes, but potentially with a different set of included files than expected.
As in: with the same qt5-config options, but different qt5-unrelated options (e.g. related to target), the qt5 build results in a different set of files.
That might be fine, if it would explicitly depend on a config option (e.g. "if not mips"), but simply not failing when files didn't get created/generated, sounds like the wrong approach and there's no way to tell why that happened, except files were not present for whatever reason.

[titobrasolin]

Thanks for raising this, Mirko.

Looking at how Qt handles this upstream: EGLFS device integration backends have been designed as autodetected/optional since this commit introduced the plugin architecture — when no preferred backend is configured, Qt tries available plugins in unspecified order and falls back to the built-in integration if none succeed. Current Qt docs describe the same logic still applying: backend selection depends on what's available (drm/gbm, etc.), not a fixed switch.

So which egldeviceintegrations/*.so files get produced for a given target depends on what Qt's configure detects in that target's sysroot, which can vary across architectures even with identical qt5base-related OpenWrt config — matching what #104 describes. In that sense, the wildcard check reflects the same "optional by design" behavior Qt applies at runtime, rather than masking an unrelated failure.

That said, the concern about silent skips still seems valid — there's no way from the log alone to tell "not applicable here" from "should have been built but wasn't." Adding a $(warning ...) when a plugin is skipped could keep the build tolerant while making the skip visible. Open to other approaches if there's a better fit.

[openwrt]

Formality Check: Suggestions Available

We checked this pull request against the contribution guidelines. Here is what needs your attention:

⚠️ STYLISTIC WARNINGS & SUGGESTIONS

Package Release Audit:

• ⚠️ Content changed in these packages, but without a PKG_RELEASE or version bump:

  • frameworks/qt5

  Increment PKG_RELEASE by 1 (or bump PKG_VERSION/PKG_SOURCE_DATE and reset PKG_RELEASE to 1) so users receive the update.

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

---

_{Something broken? Consider reporting an issue.
Running version 0e15d1c deployed on 2026-08-12 22:36:32 CEST}

[titobrasolin]

Pushed an update (force-push, amended 7ce891b -> 2844ef1) addressing the two open points:

• libdrm dependency (L228, linuxfb plugin): made it conditional on BUILD_qt5base-gui_DRM instead of always-on, so a build that explicitly disables DRM support won't carry it either:

  -  DEPENDS+=+qt5base-core +qt5base-gui +libfreetype +libdrm +PACKAGE_qt5base-input-autodiscovery:libudev +PACKAGE_qt5base-plugin-input-libinput:libinput
  +  DEPENDS+=+qt5base-core +qt5base-gui +libfreetype +BUILD_qt5base-gui_DRM:libdrm +PACKAGE_qt5base-input-autodiscovery:libudev +PACKAGE_qt5base-plugin-input-libinput:libinput

• Silent skips in the eglfs wildcard checks (L~638): added $(warning ...) on each of the four conditional installs in Package/qt5base-plugin-platforms-eglfs/install, so a missing libQt5EglFsKmsSupport.so, libQt5EglFSDeviceIntegration.so, libqeglfs-kms-egldevice-integration.so, or libqeglfs-kms-integration.so is now surfaced during the build instead of disappearing silently. Build stays tolerant (no failure), but the "why" is now visible in the log.

libinput dependency (L170) left as-is per the discussion above — will follow up with a separate issue/PR if we decide to drop it in favor of evdev.