* fix: nvidia displayport2 bandwidth calculation fix
* move vendor specific heuristics to relevant controllers
* handle case where linkBW and dp2LinkBW are 0
* Revert "handle case where linkBW and dp2LinkBW are 0"
This reverts commit 7c805f6ebf.
* fix: use offset limits for V/F curve range
* small cleanup
* use dymamic y_sec range
* chore: add clarifying comment
---------
Co-authored-by: Ilya Zlobintsev <ilya.zl@protonmail.com>
* feat: handle VF curve without vf_tuple_base (Turing) (WIP)
* feat: handle both paths
* fix: use saved base VF curve instead of calculating from offsets when base is unsupported
* chore: force reset curve before saving it as base
The curve control loop converted PWM (0-255) to the percentage NVML
expects with `/ 2.5`, mapping a 255 PWM to 102% - outside the valid
0-100 range. A curve top point of 1.0 was therefore rejected with
INVALID_ARGUMENT, after which the daemon disabled fan control for the
GPU. Static mode was unaffected because it computes the percentage
directly as `static_speed * 100`.
The divisor should be 2.55 - the inverse of the `* 2.55` percent-to-pwm
conversion already used in this file (255 / 2.55 = 100).
* Add new GPU model to device_ids.json
Add new GPU model 'Gigabyte Gaming OC ICE RX 9070 XT' to device IDs.
* fix: use existing section
---------
Co-authored-by: Ilya Zlobintsev <ilya.zl@protonmail.com>
* Add range selection for vf curve editor
* Add shaded area and modified cursor
* Disable moving selection endpoint when editing is disabled
* Check if any points are included before setting
* Remove selection when editing is disabled
* chore: unselect vf curve when disabling editing faster
---------
Co-authored-by: Ilya Zlobintsev <ilya.zl@protonmail.com>
* feat: add hold/release cookie mechanism for profile state management
Clients that need to temporarily activate a profile had no safe
way to restore the previous state on cleanup, and concurrent clients
would silently overwrite each other's profile choice.
Introduce HoldProfile/ReleaseProfile commands modelled after
power-profiles-daemon's HoldProfile/ReleaseProfile API. Acquiring a
hold activates the requested profile and returns an opaque cookie; the
previous state is saved automatically. Releasing the cookie restores
it. Multiple concurrent holds are supported with last-write-wins
semantics — releasing the active hold falls back to the next most
recent one, and releasing the last hold restores the original state.
If the client connection drops without releasing, the hold is released
automatically.
* fix: extract type aliases for profile hold fields
* refactor: remove requester field from HoldProfile request
* refactor: improve hold lifecycle signalling
Ilya Zlobintsev
Roman Makarov
vepvlo
Christopher SnowhillandIlya Zlobintsev
Nicolas OchsnerandIlya Zlobintsev
Gabriele MuscoandGabriele Musco
Arimil
e-tho
Tunahan Yardımcı