Warning: Permanently added '18.205.20.205' (ED25519) to the list of known hosts. You can reproduce this build on your computer by running: sudo dnf install copr-rpmbuild /usr/bin/copr-rpmbuild --verbose --drop-resultdir --srpm --task-url https://copr.fedorainfracloud.org/backend/get-srpm-build-task/10988466 Version: 1.9 PID: 11847 Logging PID: 11849 Task: {'appstream': False, 'background': True, 'build_id': 10988466, 'chroot': None, 'distributions_in_build': ['centos-stream-10', 'epel-10', 'fedora-43', 'fedora-44', 'fedora-45', 'fedora-rawhide'], 'distributions_in_project': ['centos-stream-10', 'epel-10', 'fedora-43', 'fedora-44', 'fedora-45', 'fedora-rawhide'], 'package_name': 'dms', 'project_dirname': 'dms-git', 'project_name': 'dms-git', 'project_owner': 'avengemedia', 'repos': [], 'sandbox': 'avengemedia/dms-git--https://api.github.com/users/bbedward', 'source_json': {'clone_url': 'https://github.com/AvengeMedia/DankMaterialShell.git', 'committish': 'e809733e3a873fd64bf18119be4a5e8d64194b98', 'spec': 'distro/fedora/dms-git.spec', 'srpm_build_method': 'rpkg', 'subdirectory': '', 'type': 'git'}, 'source_type': 8, 'submitter': 'https://api.github.com/users/bbedward', 'task_id': '10988466'} Running: git clone https://github.com/AvengeMedia/DankMaterialShell.git /var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell --depth 500 --no-single-branch --recursive cmd: ['git', 'clone', 'https://github.com/AvengeMedia/DankMaterialShell.git', '/var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell', '--depth', '500', '--no-single-branch', '--recursive'] cwd: . rc: 0 stdout: Submodule path 'dank-qml-common': checked out '26396ce432d6c71c3f5367438f96f4a8d667e160' stderr: Cloning into '/var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell'... Submodule 'dank-qml-common' (https://github.com/AvengeMedia/dank-qml-common.git) registered for path 'dank-qml-common' Cloning into '/var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell/dank-qml-common'... Running: git checkout e809733e3a873fd64bf18119be4a5e8d64194b98 -- cmd: ['git', 'checkout', 'e809733e3a873fd64bf18119be4a5e8d64194b98', '--'] cwd: /var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell rc: 0 stdout: stderr: Note: switching to 'e809733e3a873fd64bf18119be4a5e8d64194b98'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at e809733e feat(display): per-output ICC color profiles and color temperature (#3388) Generated rpkg config: [rpkg] preprocess_spec = True [git] anon_clone_url = https://github.com/%(repo_path)s [lookaside] download_url = https://${git_props:remote_netloc}/repo/pkgs/%(repo_path)s/%(filename)s/%(hashtype)s/%(hash)s/%(filename)s Writing config into /var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/.config/rpkg.conf Running: rpkg srpm --outdir /var/lib/copr-rpmbuild/results --spec /var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell/distro/fedora/dms-git.spec cmd: ['rpkg', 'srpm', '--outdir', '/var/lib/copr-rpmbuild/results', '--spec', '/var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell/distro/fedora/dms-git.spec'] cwd: /var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell rc: 0 stdout: Wrote: /var/lib/copr-rpmbuild/results/dms-git.spec Wrote: /var/lib/copr-rpmbuild/results/dms-0.0.git.4744.e809733e-1.src.rpm RPM build warnings: stderr: git_repo_pack: archiving /var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell: commit e809733e3a873fd64bf18119be4a5e8d64194b98 (HEAD, origin/master, origin/HEAD, master) Author: Minghao YU <128968671+KIDult2226@users.noreply.github.com> Date: Tue Sep 15 23:45:35 2026 +0800 feat(display): per-output ICC color profiles and color temperature (#3388) * feat(display): per-output ICC color profiles and color temperature Rebuild of #3388 on current master: the previous branch was cut from an older base and reverted unrelated fixes in the gamma stack and the display settings UI. ICC profiles: - core/internal/icc: ICC v2/v4 parser (TRC, LUT8/16 and parametric curves, vcgt, description/version/color space) plus gamma ramp generation, with synthetic coverage and optional vendor-profile tests (ICC_TEST_DIR). - wayland manager: load iccProfiles from the compositor's DMS config dir, build the ramp from the profile when one is set (falling back to the temperature ramp when it is missing or unparsable), and re-apply on output hotplug and after resume. - ICC ramps apply while the night light schedule is disabled; outputs without a profile keep an identity ramp. - desc/mluc offsets are validated before slicing, so a malformed profile returns an error instead of panicking the daemon. Per-output temperature: - outputTemps in the same config; SetOutputTemp accepts 1000-10000K and the Display Config slider exposes 3000-10000K, which matters for displays calibrated at a higher white point (e.g. a 7000K profile). Gamma control lifecycle: - needsControls() now keeps the controls alive for configured ICC profiles and per-output temperatures, so toggling the night light off no longer destroys the controls and drops the ramps. - Re-apply paths clear the per-output dedup state instead of adding a manager-level guard, which would have suppressed contrast-only writes and the post-resume forced resend (#1235), and left a recreated control without a ramp. - Monitor sleep/disconnect still re-establishes controls when an output comes back. IPC / CLI / UI: - wayland.icc.{getStatus,apply,remove,listOutputs,setTemp,getTemps} - dms icc list | info | apply | remove | status - Display Config output card gains a Color Profile row (browse/apply/remove with description, version, color space and active state) and a per-output color temperature slider, backed by Services/ICCService.qml. Config path: - DMSConfigDir() follows the compositor layout (niri/dms, hypr/dms, mango/dms) via the shared compositor detection and utils.XDGConfigHome(), replacing the hardcoded niri path in both the manager and `dms icc`. Tests: TZ=UTC go test ./... (60 packages ok), including red/green coverage for the icc parser bounds checks and needsControls(). * feat(icc): add `dms icc set-temp` and show per-output temps in `status` The per-output temperature override was reachable from the Display Config slider and from `wayland.icc.setTemp` over IPC, but not from the CLI. - `dms icc set-temp ` (alias `setTemp`) sets a per-output override, 1000-10000K, and 0 clears it so the output follows the night light schedule again. Range checking matches the daemon so an invalid value fails in the CLI instead of over IPC. - `dms icc status` gains a Temp column (the override in K, or `schedule`), so an override can be verified without opening the settings UI. Verified against a running daemon: `dms icc status` reports 7000K for the three overridden outputs and `schedule` for the remaining one. * feat(icc): treat the per-output temperature as the profile's reference white point The per-output temperature was documented as the white point a profile was produced at, but an output with a profile ignored it entirely: the ramp was generated from the profile and the temperature only applied to outputs without one (or as the fallback when a profile failed to parse). A display calibrated at 7000K therefore got the profile ramp, and enabling the night light had no effect on it at all. - `ProfileRampWithTemp` composes the profile ramp with the ratio between the target temperature ramp and the reference ramp, so the temperature is the white point the profile describes and the night light shifts relative to it. - `applyGamma` passes the night light temperature as the target, and `noTempTarget` when the schedule is disabled, which leaves profiled outputs at their reference white point and drives plain outputs with the neutral ramp. - The re-apply sentinel stays 0, so it cannot collide with an applied temperature. Covered by TestProfileRampWithTemp (reference == target is a no-op, warmer and cooler targets move the expected channels). Also: `dms icc set-temp` help text describes the reference-white-point semantics. * fix(icc): load the configured profiles even when controls already exist Restoring the upstream "output returned, re-establishing controls" branch made the registry handler establish the gamma controls before the startup post runs, and that post returned early on `m.controlsInitialized`, so the configured ICC profiles and per-output temperatures were never attached: every output reported "(none)" and the night light ran with defaults until the user re-applied a profile by hand. - `initializeControlsAndICC` (the startup post) loads the configuration first and only creates the controls when they are missing. - The loading is split into `loadConfiguredICC` / `applyConfiguredICCForOutput` so it can also run per output. - A hotplugged output now gets its configured profile and temperature as soon as its name is known (name handler) or when its control is created, which also makes the "re-applies on hotplug" claim in the description true. - After attaching, the output's dedup state is cleared so the ramp is written. Covered by TestManager_LoadConfiguredICCWhenControlsAlreadyExist and TestManager_AttachConfiguredICCForNamedOutput. * fix(icc): make the per-output temperature an actual target The per-output value was treated as the white point a profile was produced at, which meant a display with a profile never changed when the user set a temperature: the profile ramp was applied as measured and the value only mattered when a night light target existed. Per-display temperatures were therefore unusable on profiled outputs while the night light was disabled, which is the normal state for users who want each monitor at its own value. - `effectiveTempTarget` decides per output: a per-output override wins over the night light schedule, the schedule applies when there is no override, and `noTempTarget` means neither. `0` is "no override", not 0K. - `applyGamma` composes the override on top of the profile ramp, treating the profile as measured at 6500K (D65), and drives outputs without a profile with the same target so both paths agree. - `dms icc set-temp` help text and the Display Config slider description go back to describing an independent per-output temperature. Covered by TestEffectiveTempTarget (override wins, schedule fallback, none) and the updated TestProfileRampWithTemp (7000K cools, 5000K warms relative to the 6500K reference). * feat(icc): show the profile details in Display Config The profile row only showed the description, so there was no way to tell which profile a display actually has applied (whitepoint, curve type, file provenance) without leaving the settings page. - `ICCStatus` carries the descriptive metadata: class, tone-curve kind (plus gamma or table size), vcgt channels/entries, white point chromaticity with a derived CCT and standard illuminant name, file size and mtime. - `internal/icc` gains `WhitePointXY`, `WhitePointCCT` (McCamy), `WhitePointName` (D50/D65) and `TRCKind`, all covered by tests. - Display Config's Color Profile row gets an info button that opens `ICCProfileInfoModal` with those fields and the profile path, alongside the existing browse/remove actions. - `dms icc info` reports the white point as name/xy/CCT instead of raw XYZ. * fix(icc): keep the daemon, the state snapshot and the temp slider honest A malformed profile could still take the daemon down, the ICC getters ran off the wayland actor goroutine, the pushed state hid a removal, and the per-output temperature slider dropped wheel changes. - `internal/icc`: the tag table was sized with `uint32` arithmetic, so `tagCount*12` wrapped (`0x15555556*12 == 8`) and a 140-byte profile passed the bounds check, allocated ~4.3 GB and then panicked. `ParseFile` runs on the wayland actor goroutine, which has no `recover()`, so a bad profile persisted in `wayland.json` took the daemon down at startup. The count is now compared against the bytes that are actually left before anything is sized with it. - The manager publishes an ICC snapshot (`iccStatus`/`iccTemps`) whenever the actor changes an output's profile or temperature, and `GetICCStatus`/ `GetOutputTemps` serve that snapshot instead of ranging `m.outputs` and reading fields the actor owns. That removes the data race reported by `go test -race` for `dms icc status` running against a hotplug, and keeps the per-profile `os.Stat` off the night light animation path, where it ran on every `updateStateFromSchedule` (including each 25 K step). - `State.ICCProfiles`/`OutputTemps` drop `omitempty`, so removing the last profile pushes `{}` instead of omitting the key: the QML truthiness guard then clears `ICCService.status` instead of leaving the removed profile on screen with a green "active" dot. - `removeOutputByRegistryName` (extracted from the registry remove handler) deletes the `outputNames`/`outputRegNames` entries along with the output, so a disconnected monitor stops being listed by `dms icc status`/`listOutputs`, and a rebound `wl_output` reusing the released object ID cannot attach the previous monitor's profile from the stale name. - The per-output temperature slider sets `wheelEnabled: false` like the other drag-finished sliders: `DankSlider`'s wheel handler assigns `value` and emits `sliderValueChanged` without `sliderDragFinished`, so scrolling dropped the change, froze the label on the scrolled value and destroyed the value binding. Covered by TestParseBytesTagTableBounds (allocates 4,299,161,600 bytes at parser.go:138 and dies with an unrecovered fatal error on the previous commit), TestManager_ICCStatusServesPublishedSnapshot, TestManager_RemoveOutputByRegistryNamePrunesNames and TestManager_ICCStatusConcurrentPublishAndRead; a temporary copy of the getter test against the previous commit reports DATA RACE and passes here. * fix(icc): keep the attached profile when a gamma control is re-created `setupOutputControls` stored a fresh `outputState` for every output it touched, and `createControls` calls it whenever the controls are rebuilt, so recreating a control dropped the output's `iccPath`/`iccProfile`/`outputTemp` — configured state that does not belong to the control. The path is dormant today because `destroyControls` only runs when nothing is configured (`needsControls()` covers `ICCProfiles`/`OutputTemps`), but the snapshot published after `createControls` would then report whatever the rebuilt state holds instead of the profile the display is configured with. `controlStateFor` reuses the state of a known output and resets only what belongs to the new control: the ramp bookkeeping and the failure budget (rampSize, failed, retryCount, lastFailTime, lastTemp, lastGamma, lastContrast). A control that has not reported gamma_size yet has to receive its ramp again, while the profile and the per-output temperature survive. An output seen for the first time still starts from a clean state. Covered by TestManager_ControlStateReuseKeepsAttachedICC. * fix(icc): keep the config a real snapshot and make the per-output temperature apply Third review round. - `Config` is copied by value all over the manager, but `ICCProfiles` and `OutputTemps` are maps, so every copy aliased the ones the manager writes under `configMutex`. `updateStateFromSchedule` stored such a copy in `m.state` and it was marshalled on the connection writer goroutine while `ApplyICC` stored a profile from the IPC goroutine (`fatal error: concurrent map iteration and map write`, which no `recover()` catches); `SaveConfig` marshalled its copy after the unlock, and `loadConfiguredICC`/`attachConfiguredICC` indexed the maps after releasing the lock. Every copy that outlives the lock is cloned now (`cloneConfig`/`configSnapshot`), so a value copy is a snapshot again. - `SetOutputTemp` never created the gamma controls. On a default install (night light off, gamma 1.0, contrast 1.0, no profile, no override) they do not exist, so the `Range` over `m.outputs` matched nothing: the value was written to `wayland.json`, no ramp was applied, and the settings slider snapped back to "Default" until a daemon restart. It now persists first, creates the controls through `ensureOutputControls` (shared with `ApplyICC`), and pushes the state from the actor, and the published temperatures report the configured value even before an output is known. - A TRC is not a video card gamma ramp: `rTRC`/`gTRC`/`bTRC` describe the display's own transfer function, so a gamma-2.2 profile was written as `t^(1/2.2)` — mid gray 0.5 became 47909/65535 — washing the display out instead of correcting it. `ApplyICC` refuses a profile without `vcgt`, the attach path skips one with a warning, and `GenerateGammaRamp` returns an error instead of falling back to the TRC or to an identity ramp. TRC stays profile metadata (`dms icc info`, the settings dialog). - `icc: applied ICC ramp` was logged at Info on every 25 K animation step; it is Debug now, which is where a per-step message belongs. - `I18n.tr("No information available")` in the profile info modal passes its translator context, like every other string this PR adds. Covered by TestManager_ConfigSnapshotOwnsItsMaps, TestManager_ConfigSnapshotConcurrentMarshal (the previous commit dies with `fatal error: concurrent map iteration and map write`), TestManager_SetOutputTempWithoutControlsPublishesValue (the previous commit reports 0 for the value it just stored), TestGenerateGammaRampRequiresVCGT, and the updated TestProfileRampWithTemp, whose fixture now carries an identity vcgt table instead of relying on an empty profile. * fix(icc): push the state when only the ICC part changed Found while sweeping the same class of problem: `stateChanged` compared only the schedule fields, so a change that touches nothing else — applying or removing a profile, `dms icc set-temp` — was treated as "no change" and the notifier never pushed it. The settings page then only caught up because the UI path calls `requestStatus()` afterwards, and the CLI path did not catch up at all, which is the symptom the omitempty fix was meant to remove. `iccStateChanged` compares the ICC profile status and the per-output temperatures, so those changes reach the subscribers on their own. Covered by the new TestStateChanged cases (profile applied, profile removed, profile description changed, output temp changed, unchanged ICC state); the four change cases report `stateChanged() = false` on the previous commit. * fix(icc): keep the night light state, prune names without a control, use a 0 sentinel Fifth review round. - `SaveICCConfig` replaces `SaveConfig` on the three ICC paths (apply, remove, set-temp). Writing the daemon's whole config persisted the night light fields it happens to hold in memory: with the night light on, applying a profile stored `"Enabled": true`, and since the shell only ever sends `wayland.gamma.setEnabled` when the mode is on, turning it off afterwards (an in-memory change on the daemon side, no write) left that `true` on disk — after log out/in the daemon came up driving the schedule while the UI showed night mode off, with no way to resync short of a toggle. The ICC save now reads the file and rewrites only `iccProfiles`/`outputTemps`, so the fields the shell owns stay as they are. - `removeOutputByRegistryName` resolved the output from `m.outputs`, which only has entries once the gamma controls exist. On a default install (night light off, no profile, no override) no control is ever created, so a disconnected monitor kept its `outputNames`/`outputRegNames` entries for the life of the daemon: `dms icc status`/`listOutputs` listed monitors that were gone, and both maps grew with every dock/undock cycle. The object ID is resolved from `m.outputRegNames` (populated for every `wl_output`), the name entries are dropped before the output state is looked up, and a state that is known without a registry name still falls back to matching its own. - The Display Config temperature row used `7000` as its fallback for an output with no override. `publishICCState` only copies entries with `temp != 0`, so the value is absent rather than `0` for an unconfigured output: the card claimed "7000K" while the daemon drove the night light or neutral, and a user who deliberately set 7000K got the "no override" colouring because the highlight tested `!== 7000`. The sentinel is `0` now, which is what the `Default` label branches and the "is overridden" tests were written against. Covered by TestSaveICCConfigKeepsNightLightFields (the previous commit brings the night light back on after a restart), TestManager_RemoveOutputByRegistryNameWithoutControl (the previous commit keeps an unplugged monitor listed) and the existing TestManager_RemoveOutputByRegistryNamePrunesNames. * fix(icc): validate the CLI arguments and the IPC parameters of the ICC commands Sweep of the two surfaces the review has not looked at yet, so the failures are found here instead of in the next round. - `dms icc apply` copied the profile into the config directory before asking the daemon, and only the *parse* was checked locally. A profile the daemon refuses (no `vcgt` table, non-RGB color space) was therefore left in the profile directory for `dms icc list` to keep offering, and an IPC failure left the copy behind as well. The command now checks the same rules the daemon enforces before copying anything, and removes the copy it just made when the request fails (a file that was already there is left alone). - `dms icc list` marks a profile without a `vcgt` table, so the rule that makes `apply` refuse it is visible where the profiles are listed. - `ApplyICC`/`RemoveICC`/`SetOutputTemp` reach the manager over IPC with whatever the caller sent: an empty (or whitespace-padded) output name used to be persisted as an entry in `wayland.json` that no `wl_output` can ever match, and a relative profile path was stored to be resolved again on the next start, from a different working directory. Both are rejected now, before anything is written. Verified with the built CLI against the previous binary: with a profile that has no vcgt table, `dms icc apply` now exits before touching the config directory (`residual=[]`) where the previous one copied the file and went on to the IPC (`residual=[nogamma.icc]`); with a valid profile and no daemon reachable, the previous one leaves `vcgt.icc` behind and this one does not. Covered by TestManager_RejectsInvalidICCArguments. * fix(icc): apply the user gamma and contrast on profiled outputs * fix(icc): recreate failed controls without the night light and allow clearing a per-output temp * test(icc): cover the recreated control and the cleared temperature override Follow-up on d55d3d1f, which fixed both points without tests: - TestManager_RecreateOutputControlFollowsNeedsControls pins the predicate: with the night light off and nothing configured there is nothing to recreate, and with a configured profile or a per-output temperature the control has to be recreated. Both configured cases return nil on 9226251c. - TestManager_SetOutputTempZeroClearsTheOverride pins what the reset button in Display Config does end to end: the stored value and the published entry both disappear, so the row reads "Default" and the output follows the schedule. Also keeps the reset button's slot instead of revealing it on demand. The temperature row shares its column with the slider below it, so the height change between "Default" (no button) and an override moved the slider 14 px under the pointer while it was being dragged; the button is now always laid out and only its opacity and enabled state follow the override, which also lets the label width drop the conditional. * fix(icc): replicate a one-channel vcgt and keep the temp slider in sync * fix(icc): release idle gamma controls and push the output list * fix(icc): dedupe ramps on the effective target * fix(icc): never overwrite a same-named profile in the config dir --------- Co-authored-by: bbedward git_repo_pack: Wrote: /var/lib/copr-rpmbuild/results/DankMaterialShell-e809733e.tar.gz git_pack: archiving /var/lib/copr-rpmbuild/workspace/workdir-jrtsqa4v/DankMaterialShell/dank-qml-common: commit 26396ce432d6c71c3f5367438f96f4a8d667e160 (HEAD) Author: bbedward Date: Wed Sep 2 15:06:50 2026 -0400 i18n: sync git_pack: Wrote: /var/lib/copr-rpmbuild/results/dank-qml-common.tar.gz warning: Downloading https://go.dev/dl/go1.26.5.linux-amd64.tar.gz to /var/lib/copr-rpmbuild/results/go1.26.5.linux-amd64.tar.gz warning: Downloading https://go.dev/dl/go1.26.5.linux-arm64.tar.gz to /var/lib/copr-rpmbuild/results/go1.26.5.linux-arm64.tar.gz warning: %source_date_epoch_from_changelog is set, but %changelog has no entries to take a date from Downloading https://go.dev/dl/go1.26.5.linux-amd64.tar.gz to /var/lib/copr-rpmbuild/results/go1.26.5.linux-amd64.tar.gz Downloading https://go.dev/dl/go1.26.5.linux-arm64.tar.gz to /var/lib/copr-rpmbuild/results/go1.26.5.linux-arm64.tar.gz %source_date_epoch_from_changelog is set, but %changelog has no entries to take a date from Output: ['go1.26.5.linux-arm64.tar.gz', 'dank-qml-common.tar.gz', 'DankMaterialShell-e809733e.tar.gz', 'dms-git.spec', 'dms-0.0.git.4744.e809733e-1.src.rpm', 'go1.26.5.linux-amd64.tar.gz'] Running SRPMResults tool Using distributions_in_build for this build. Extracting arch-specific tags for centos-stream-10 Extracting arch-specific tags for epel-10 Extracting arch-specific tags for fedora-43 Extracting arch-specific tags for fedora-44 Extracting arch-specific tags for fedora-45 Extracting arch-specific tags for fedora-rawhide Package info: { "architecture_specific_tags": { "centos-stream-10": {}, "epel-10": {}, "fedora-43": {}, "fedora-44": {}, "fedora-45": {}, "fedora-rawhide": {} }, "name": "dms", "epoch": 2, "version": "0.0.git.4744.e809733e", "release": "1" } SRPMResults finished