https://bugs.kde.org/show_bug.cgi?id=494522
Sanfod Rockowitz <rockow...@minsoft.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rockow...@minsoft.com
--- Comment #23 from Sanfod Rockowitz <rockow...@minsoft.com> ---
I'm the developer of ddcutil.
I have added, in branch 2.1.5-dev, option ***--disable-ddc** to disable DDC
communication for a single monitor model. It takes as an argument a monitor
model identifier, for example ***--disable-ddc SAM-U32H75x-4578***. The
identifier is the same used to construct the file name of the user defined
features file, and is now also reported by **ddcutil detect --verbose**.
Probably the most useful way to specify this option in the ddcutil
configuration file ddcutilrc. If specified in the [global] section, it applies
to both the **ddcutil** command and the the shared library. If specified in
the [libddcutil] section, it applies only to the shared library, which is what
PowerDevil uses.
If useful, the libddcutil API could be extended to expose this ability.
A few comments on various comments:
- Re status DDCRC_OK when setting a feature value. Depending on configuration,
**setvcp** or its API equivalent, may or may not attempt to read the feature
value after setting it. Unless verification is enabled, all DDCRC_OK means is
that the monitor acknowledges receipt of a DDC request packet. There is no
guarantee that is has successfully acted on the request. When verification is
enabled, **setvcp**, or its API equivalent, essentially performs a **getvcp**
operation to verify that the value has been set.
- Re a DDCRC_NULL_RESPONSE status. The monitor has returned a DDC NULL Message
in response to a request. Though sometimes abused for other purposes by some
monitors that don't conform to the DDC/CI spec, in this context it pretty
clearly means that the monitor was unable to formulate a valid reply for some
reason, e.g. monitor state.
- Re "ddcutil --display=1 setvcp 10 50" reporting "Display not found", this
means that no monitors were detected during ddcutil initialization, so the
there is no "--display=1" . Note also that "--display 1" is superfluous. If
no display is detected, ddcutil defaults to operating on the first display
detected.
- I'm unclear as to what is meant by a display "crashing". What exactly is the
behaviour seen? Similarly, what does "rebooting" mean?
- Re "setvcp 10 xx" failing, in some modes, e.g. Cinema, Gaming, HDR, some
monitors will reject requests to change brightness and related features.
Perhaps the high frame rate is one of those situations.
Finally, regarding monitors repeatedly disconnecting and reconnecting, my
Samsung U32H750 will sometimes go blank when other monitors are being turned
on/off and appear to be disconnected. It few seconds later an image appears
the monitor is detected as connected. That's why you see the "Delaying 6
seconds to avoid a false disconnect/connect sequence..." messages in the logs.
--
You are receiving this mail because:
You are watching all bug changes.
