See inline.

Updates to mkpriv

In D58118#1333583, @jrtc27 wrote:

I don't see any of this upstream at https://gitlab.com/alfix/bsddialog, nor even as a merge request there?

Worth repeating:

Add mkpriv update Makefile to produce priv.d

This work supports the incoming bsdpv(3) library and bsdpv(1) utility -- which is dpv(3)/dpv(1) rebuilt to use bsddialog(1) instead of cdialog(1) that was removed from base

Amended the squashed commit message to fold in the second batch (hang, jail, dtmalloc, mib, sched-latency, io-slow) and to note taint scope: no kernel changes, libexec profiles plus priv.d only. Tip commit is now 176b3b389fde (tree unchanged from c029c0fb59f4).

Adversarial parser fuzzing (ASan/UBSan) found and fixed two figpar-inherited memory-safety bugs: NULL directive buffer on an empty-name line, and a bsdconf_strexpand() heap over-read/over-write when a value shrinks as backslash escapes collapse (plus a one-byte over-read on a trailing backslash)

Adopt the abridged license form per style(9) and the FreeBSD license guide across all new files (requested by ziaee): copyright lines first, then SPDX-License-Identifier: BSD-2-Clause, dropping the full 2-clause text

Touch-ups: --version prints '1.0 Jul-6,2026' (sysrc format), -h/--help advertise name[[+|-]=value], SYNOPSIS renders name[[+|-]=value] via sysrc.8's mdoc idiom

Defaults-aware reads: the defaults file is always scanned first (like the boot loader), so 'sysconf loader acpi_video_load' reports the effective boot value; the defaults slot is read-only and never appears in -l/-L, write targeting, or removals

Add rc pass-through to sysrc(8) (all arguments verbatim, unvalidated), sysrc-style name+=word/name-=word list editing for non-make targets, and --version

Allow -A with -D as in sysrc(8): -D's scoping wins, -A keeps its dump-implying role, so -ADd describes all defaults and only defaults

Let -d compose with the dump flags as in sysrc(8): -ad/-Ad/-aDd dump descriptions of every directive in scope; sysctl -ad pairs configured directives with kernel OID descriptions

Honor loader_conf_files discovery from /boot/defaults/loader.conf (kevans); add sysrc-style -d/-D/-A defaults querying, LOADER_DEFAULTS, and a FILES section

Echo 'name: old -> new' on writes after the fashion of sysctl(8)/sysrc(8), silenced by -q

I think I might update the code to print the before/after value. I think it should, when setting a value, like sysrc(8), show (for example) <old> -> <new>

Playing around (and yes, my hostname is literally "BSDCan2026" because this is running on my Framework Laptop 12 that I purchased just-prior-to and took to BSDCan 2026 conference):

@ziaee thank you for bringing this to my attention -- happy to review

👍

@olce — thanks again, and good call on the term. I've updated the diff: "sleep event" is gone in favor of the spec's wording — the comment now names the 0x80 path as the "S0 Power/Sleep Button Pressed" notify and 0x02 as "Device Wake," so nothing is mislabeled (this also covers Daniel's note on the same line). It's a comment-only change with no functional difference from what you accepted, so it should be a quick re-look.

Reword the grace-window comment to use the ACPI spec's exact notify names: 0x80 = "S0 Power/Sleep Button Pressed", 0x02 = "Device Wake" (was loosely called a "sleep event"). Addresses olce's and Daniel's review feedback on the wording at the replay-window comment. No functional change.

In D55424#1328418, @des wrote:

Here's a preview of the conversion: https://git.des.dev/des/dpv

As soon as you give me the go-ahead, I will push this to its intended location.

@asiciliano I don't think anyone wants to see LGPL re-infect the base.

In D55424#1328125, @des wrote:

Do you prefer GitHub or Codeberg, and what is your login there? Or would you prefer to host the repository yourself somewhere else?

In D55424#1328049, @des wrote:

or ports, if you want separate ports for each component

In D55424#1328049, @des wrote:

In D55424#1328036, @dteske wrote:

How does one construct a port to install software that has no home? Does that fall on me to rip it out an old base and port it to GitHub without the benefit of the FreeBSD build infrastructure?

We extract the source with complete history into a separate repository under the FreeBSD organization either on GitHub or on Codeberg, unless you prefer to host it somewhere else. We'll have to replace some of the missing build glue, but that's easily done. See for instance OPIE.

So, the question begs to be asked:

In D55424#1327998, @des wrote:

In D55424#1327980, @dteske wrote:

Does bsddialog have an interface that is similar to dpv?

Yes, bsddialog_progressview(). It's undocumented but it was developed specifically to replace libdpv in the installer.

In D55424#1327945, @des wrote:

In D55424#1327941, @dteske wrote:

In D55424#1327936, @des wrote:

To what end?

1. bsdinstall for dist-based installations
2. bsdconfig packages
3. for utilization by humans that use the operating system

They've already been replaced in bsdinstall and bsdconfig, and “humans that use the operating system“ can install them from ports after we convert them.

In D55424#1327936, @des wrote:

In D55424#1327922, @dteske wrote:

I obviously do not want to see dpv, libdpv, and libfigpar removed from base. I would like to update them.

To what end? Nothing in base uses them and they've been disconnected since 2023. They're gone from 14 and 15 already. We offered to move them to ports months ago.

I obviously do not want to see dpv, libdpv, and libfigpar removed from base. I would like to update them.

In D55424#1327904, @des wrote:

@dteske have you given this any further thought?

@git_danielschaefer.me — thank you, pulling that AML is exactly the right place to look.

Add 'MFC after: 2 weeks' to give the change soak time on HEAD before merging back.

Restore the pre-existing 'ACPICA Event Handlers' section comment to its function (acpi_invoke_sleep_eventhandler); the replay-window comment, define, and helper now sit above that header as a self-contained block. No functional change.

@olce -- thanks for the review; I've worked in all of it. Summary of this update:

@adrian -- thanks for pushing on this; asking for real traces was the right call and it turned up more than I expected.

Move the replay guard back inside the #if defined(amd64) || defined(i386) block in acpi_event_power_button_sleep(), per olce's note that the non-x86 paths don't support suspend/resume anyway. No functional change on x86.

Rework per review: take the resume timestamp before DEVICE_RESUME() to close a race the instrumentation exposed (PR 296243); window 1s (replay measured ~600 ms from that anchor); condense comments; move the guard ahead of the arch #if so it also covers the non-x86 path; rebased on current main.

@adrian -- good call on the PR; I'll open one and dump the bootverbose traces, the EC _Qxx timing, and the per-cycle timestamps there, then link it from the comment block so the "why" survives long after our short-term memory fades. (Noted for the i2c one too.)

@guest-seuros — thank you for the testing; validating across Apple, MSI, Gigabyte, Intel, Lenovo, Sony, Panasonic, Toshiba, AZW, Minisforum, Qotom, Beelink and coreboot is real work, and it's useful: it scopes the replayed-0x80 behavior tightly, which makes a guard easy to reason about.

In D57712#1324224, @git_danielschaefer.me wrote:

Hmm we don't have any issues on Linux though.
I think the system would still be asleep by the time you receive the power button event.

@obiwac — great seeing you at BSDCan! Looks like your comment came through empty on my end (which is all my "??" meant — sorry if it read as terse). I'd really value your take on this one; you know this corner of ACPI better than I do, having written the s2idle loop, and I'd rather shape it with your input than land it without. Whenever you get a sec, mind re-posting whatever didn't make it through?

@guest-seuros — thanks for digging into this, and for offering to test on hardware you have on hand; more data points across machines would be genuinely valuable, so please do share what you find.

In D57712#1323580, @git_danielschaefer.me wrote:

I checked the firmware behavior, it first triggers a wake-up via PWRBTN# pin

Here is how linux handles it: https://github.com/torvalds/linux/commit/e71eeb2a6bcc
It does not have a timeout, it just ignores powerbutton ACPI notify events in sleep, it requires a wake source.

Linux systemd HoldoffTimeoutSec defaults to 30 seconds where all events are ignored after a resume for a spell.

Documentation says just lid events are ignored, so not power button, so this is probably not the same logic.
https://www.freedesktop.org/software/systemd/man/latest/logind.conf.html#HoldoffTimeoutSec=

In D57712#1324106, @obiwac wrote:

In D57712#1323300, @guest-seuros wrote:

Do you know which firmware stack your machine is running ?

In D57712#1323300, @guest-seuros wrote:

One question: is the Framework running the latest BIOS/EC firmware available? A lot of suspend/resume bugs end up being fixed in firmware updates, especially around button handling, debounce logic or device reattachment during resume.

In D57712#1323294, @guest-seuros wrote:

I m not fully convinced this is a firmware issue.

While debugging ACPI, I have seen cases

In D57712#1323294, @guest-seuros wrote:

do other operating systems have to carry a similar quirk for this hardware? This laptop is well tested in arch linux, so someone must have noticed this.

Address review: consolidate the un-idle/restore handshake into ig4iic_set_config() behind a force_restore argument (per adrian) so ig4iic_resume() no longer duplicates it; warn if the core never leaves reset after the COMP_TYPE poll; restore the matching pause() in the handshake.

Address review (imp): hide the ignore message behind bootverbose and report elapsed time in microseconds.

Without verbose boot, the message is gone.