Merge pull request #355 from ghostbsd/dependabot/pip/contrib/libcbor/doc/source/jinja2-3.1.6
build(deps): bump jinja2 from 3.1.5 to 3.1.6 in /contrib/libcbor/doc/source
Merge pull request #353 from ghostbsd/dependabot/pip/contrib/libcbor/doc/source/certifi-2024.7.4
build(deps): bump certifi from 2023.11.17 to 2024.7.4 in /contrib/libcbor/doc/source
devel/libchdr: Update to g20241211
* remove USES=pkgconfig and ZSTD related patch after fixing .cmake
module for archivers/zstd on i386
* exclude unbundled dependencies from extraction by setting
EXTRACT_AFTER_ARGS
Changelog: https://github.com/rtissera/libchdr/compare/b397465..cb07733
PR: 283651
textproc/cdif: Deprecate and set expiration date to 2025-04-30
Upstream repository archived on Jun 25, 2018 and recommends users
to migrate to sdif-tools (not ported)
PR: 284657
Approved by: portmgr (maintainer timeout, 1+ month)
net-p2p/shx: Deprecate and set expiration date to 2025-04-30
Obsolete protocol that has been superseded by many others
Approved by: bofh (maintainer, via Matrix)
sound: Make dev.pcm.X.mode dynamic
Currently dev.pcm.X.mode is calculated only once in pcm_sysinit(), which
is called by pcm_register() during attach, but this can result in
inconsistencies.
For some context, what pcm_mode_init() does is, it checks if "playcount"
is positive, in which case we assume the device supports playback. The
same is done for "reccount" for recording, and if "mixer_dev" is not
NULL, we know the device has a mixer.
The "playcount" and "reccount" variables correspond to the number of
_primary_ playback/recording channels, so we can assume that the primary
channels have been created before reaching pcm_mode_init(). However, for
the mixer that's not always the case. If the mixer is created _after_
pcm_register(), as is the case for snd_dummy(4) for example,
pcm_mode_init() will see that "mixer_dev" is NULL, and report that the
device does not have a mixer, whereas in reality we just created it
afterwards.
[8 lines not shown]
sound: Retire SD_F_AUTOVCHAN
This flag is redundant and essentially a no-op, as it is set when the
device supports at least playback or recording, which is almost always
the case. But even if the device is mixer-only (i.e., 0 channels), there
is no reason to keep this flag; it is only used to bail out of the vchan
sysctl handlers, but we already bail out anyway if we try to use the
sysctl in a vchan direction that is not supported.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49021
sound: Take dsp_cdevsw out of header file
Not used outside of pcm/dsp.c.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D49217
sound: Simplify pcm/feeder_mixer.c
- Get rid of macro magic.
- Make feed_mixer_info handling similar to most feeders.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48394
