* Vulkan: fixes driver name concatenation on multi-GPU systems
applyDriverName appended to the result buffer without clearing it. When
a later device reported a higher API version, its driver name was
appended to the name of the earlier device instead of replacing it, as
the comment in detectVulkan intends.
* CHANGELOG: moves the #2615 entry to Unreleased
#2616 was opened after 2.69.0 had been released, but its entry was
written under 2.69.0 Bugfixes, so the changelog listed the fix as part
of 2.69.0.
DDC/CI results never set `builtin`, and FF_LIST_ADD does not zero the new
element, so external monitors were reported as built-in or external at
random. Set it to false, as the BSD DDC/CI backend does.
FF_SUPPRESS_IO() was declared inside the `if (ffddca_init)` block, so its
cleanup restored stdout before display detection ran and libddcutil trace
lines could reach the output, ahead of `--format json` too. Declare it at
function scope so it covers the whole detection, including the
FF_DISABLE_DLOPEN build.
Closes#2615
FreeBSD 16.0-CURRENT's <string.h> now provides C23-style
qualifier-preserving wrappers for the string search functions. Besides
the prototype, `memrchr` (like `memchr`, `strchr`, `strstr`, `memmem`,
...) is also defined as a function-like macro built on `_Generic`:
#define memrchr(b, c, n) __qualsel((b), \
(const void *)(memrchr)((b), (c), (n)), (memrchr)((b), (c), (n)))
`common/memrchr.h` redeclares the function unconditionally. When
<string.h> has already been included, that declaration is expanded by
the macro and every translation unit fails with:
src/common/memrchr.h:11:7: error: expected identifier or '('
11 | void* memrchr(const void* s, int c, size_t n);
A libc that defines `memrchr` as a macro has necessarily declared the
function it wraps, so skip our declaration in that case. Nothing
changes on platforms where `memrchr` is not a macro, and the fallback
implementation is still selected by `check_function_exists`.
/proc/cpuinfo on sparc has none of the fields the generic fallback looks
for, so the module printed "Unknown (64)". The name is in "cpu", and the
frequency in "Cpu<n>ClkTck" -- in Hz, hex on sparc64, decimal on sparc32.
Joshua Rogers