Skip to content

RFE: redesign nutdrv_qx subdriver matching to keep track of POSSIBLY_SUPPORTED driver-device pairs #3704

New issue
New issue
Open
Open
RFE: redesign nutdrv_qx subdriver matching to keep track of POSSIBLY_SUPPORTED driver-device pairs#3704
Labels
Incorrect or missing readingsOn some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.)Qx protocol driverDriver based on Megatec Q<number> such as new nutdrv_qx, or obsoleted blazer and some othersVolunteers welcomeCore team members can not commit to these tasks, but community would benefit from their completionenhancementneed testingCode looks reasonable, but the feature would better be tested against hardware or OSesrefactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warnings
Milestone
NUT 2.9

Description

@jimklimov
jimklimov
opened on Sep 23, 2026

Originally discussed in #3658

This feature is used in usbhid-ups, so when a subdriver mapping suspects it might support the device somehow but it is not an exactly known-supported model (e.g. generally from same vendor), so some different subdriver might know more about it, the claim methods return a POSSIBLY_SUPPORTED value. If by the end of the loop no subdriver authoritatively asserts that the device is SUPPORTED by it, we can backtrack to next-best options.

In case of nutdrv_qx, per #3659 some subdrivers currently change dstate as soon as they investigate the device (e.g. set vendor/model names etc.) and the claiming loop ends as soon as there is a non-zero reply, so some redesign would be needed. And testing on real devices...

Activity

  1. jimklimov
    added this to the NUT 2.9 milestone on Sep 23, 2026
  2. jimklimov
    added
    enhancement
    need testingCode looks reasonable, but the feature would better be tested against hardware or OSes
    refactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warnings
    Qx protocol driverDriver based on Megatec Q<number> such as new nutdrv_qx, or obsoleted blazer and some others
    Incorrect or missing readingsOn some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.)
    Volunteers welcomeCore team members can not commit to these tasks, but community would benefit from their completion
    on Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Incorrect or missing readingsOn some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.)Qx protocol driverDriver based on Megatec Q<number> such as new nutdrv_qx, or obsoleted blazer and some othersVolunteers welcomeCore team members can not commit to these tasks, but community would benefit from their completionenhancementneed testingCode looks reasonable, but the feature would better be tested against hardware or OSesrefactor/fightwarnPR or issue proposal to improve code maintainability without functional changes, or to fix warnings

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions