One package in this from-scratch build's KDE stack contains no compiled code at all. It's a database of hardware IDs — PCI, USB, and PNP vendor and device names — and it exists only because a different package's build script checks for a specific file at configure time, before anything about hardware detection actually matters at runtime.
What actually needed it
libdisplay-info, a small library needed by kwin for parsing monitor EDID data, isn't in BLFS's own KDE chapter — it's a dependency this build added on its own. Its meson.build looks for a pkg-config package named hwdata; if that isn't found, it falls back to checking for a hardcoded path, /usr/share/hwdata/pnp.ids, directly. On a from-scratch system that has never installed anything called hwdata, neither check succeeds, and meson doesn't proceed with a warning or a reduced feature set — it errors out and stops the configure step entirely.
A configure-time check, not a runtime one
This isn't a case of a feature quietly failing later because a data file was missing when something tried to read it during actual use. The build itself refuses to start until the file exists — a hard, immediate stop, the same kind of gate a missing library or header normally produces, just triggered by a plain text database file instead of anything compiled. Whether kwin would ever meaningfully use PNP vendor names at runtime, on a system with exactly one known monitor, is a separate question the build process never gets far enough to ask.
The fix, and why it's unusually small
hwdata got added as its own package — install the files, satisfy the check, nothing to compile, nothing to configure beyond copying data into place. It's one of the few packages in this entire project with no build step in the ordinary sense at all: no configure, no make, no compiler invoked anywhere in the process. The entire "build" is extracting a tarball to the right location.
What this says about dependency chains in practice
BLFS's own book doesn't mention hwdata anywhere in the KDE chapter, because it isn't a KDE dependency in any direct sense — it's a transitive requirement of a library this build chose to add for one narrow reason, discovered only by actually running the build and reading what stopped it. Following a documented package list correctly doesn't guarantee every real dependency gets pulled in automatically; sometimes a single hardcoded fallback path three layers down in an unrelated library's build script is the entire reason a whole extra package needs to exist.