-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running detect causes my monitor's controls to lock up. #483
Comments
That the monitor locks up is disconcerting; it's not a behaviour I've seen. Try using options --bus 6 --skip-ddc-checks to reduced the monitor interactions on the detect command. The DDC Null Message is a valid monitor reply request. It indicates that monitor is unable to form a proper reply, though some monitors abuse the spec and use a DDC Null Message to indicate that the requested feature does not exist. If you're lucky, giving the monitor more time to formulate a reply may help; Use option --sleep-multiplier 2.0 to cause ddcutil to double the time it waits between sending a request packet and attempting to read a response. Without interrogate output there's not much more I can say. |
the |
My oops. --skip-ddc-checks is applicable to all commands, but --bus only applies to single display commands like getvcp. Each reduce the overhead operations at the start of commands. To submit the interrogate output, probably simplest to click "Paste, drop, or click to add files" below the text entry area, or click on the paper clip above it. |
|
after this runs, my monitor's power button, and all other buttons, cease to reply to presses. completely locked up until disconnected from power.
fun fact: my monitor does in fact have DDC...
The text was updated successfully, but these errors were encountered: