Blue gain fails verification on second attempt

[haarp]

Hello,

using ddcui 0.0.6 and ddcutil-0.9.8 on a Dell U3818DW here. Feature 0x1a (Blue gain), and only this feature, seems to be screwy. I can change this feature once: ddcui and the monitor will accept the new value. When I change it again afterwards: The monitor accepts the new value, but ddcui complains:

Expected value: 100 (0x64), Reported value: 99 (0x63)

(0x7f7364d2d700 VcpThread::setvcp) Starting. feature_code=0x1a. sl=0x64, writeOnly=false
(0x7f7364d2d700 VcpThread::setvcp) ddca_get_nontable_vcp_value() after ddca_set_non_table_vcp_value():
(0x7f7364d2d700 VcpThread::setvcp)   opcode: 0x1a, requested sl=0x64, mh=0x00, ml=0x64, sh=0x00, sl=0x63
(0x7f7364d2d700 VcpThread::rpt_verify_error) featureCode=0x1a, expectedValue=0x64, observedValue=0x63
(0x7f7364d2d700 VcpThread::setvcp) Calling _baseModel->modelVcpValueUpdate()
(0x7f73705d8780 MainWindow::showSerialMsgBox) Starting.
(0x7f73705d8780 FeaturesScrollAreaView::onUIValueChanged) New value matches model value, Suppressing.

and resets the value in the UI back to 99, while the real value now is 100. This bug persists for further attempts at changing this value.

However, if I now change another value, (e.g. Green gain), then I can successfully change Blue gain, but only once, before this bug returns.

Weird, huh? Is this a bug in the monitor firmware or in ddcutil/ddcui?

Cheers!

[rockowitz]

The "off by one" difference between the value set and the value subsequently read is common.  I suspect it's because there's rounding error due to some integer to float conversion within the DDC chip in the monitor, but that's just a conjecture.  The latest version of ddcui (0.1.0) does not regard these "off by one" differences as an error when verifying the value set.  I'm considering whether this "tolerant" behavior should be a controlled by a UI option.

…

On 1/15/20 5:44 AM, haarp wrote: Hello, using ddcui 0.0.6 and ddcutil-0.9.8 on a Dell U3818DW here. Feature 0x1a (Blue gain), and only this feature, seems to be screwy. I can change this feature once: ddcui and the monitor will accept the new value. When I change it again afterwards: The monitor accepts the new value, but ddcui complains: |Expected value: 100 (0x64), Reported value: 99 (0x63) | |(0x7f7364d2d700 VcpThread::setvcp) Starting. feature_code=0x1a. sl=0x64, writeOnly=false (0x7f7364d2d700 VcpThread::setvcp) ddca_get_nontable_vcp_value() after ddca_set_non_table_vcp_value(): (0x7f7364d2d700 VcpThread::setvcp) opcode: 0x1a, requested sl=0x64, mh=0x00, ml=0x64, sh=0x00, sl=0x63 (0x7f7364d2d700 VcpThread::rpt_verify_error) featureCode=0x1a, expectedValue=0x64, observedValue=0x63 (0x7f7364d2d700 VcpThread::setvcp) Calling _baseModel->modelVcpValueUpdate() (0x7f73705d8780 MainWindow::showSerialMsgBox) Starting. (0x7f73705d8780 FeaturesScrollAreaView::onUIValueChanged) New value matches model value, Suppressing. | and resets the value in the UI back to 99, while the real value now is 100. This bug persists for further attempts at changing this value. However, if I now change another value, (e.g. Green gain), then I can successfully change Blue gain, but only once, before this bug returns. Weird, huh? Is this a bug in the monitor firmware or in ddcutil/ddcui? Cheers! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18?email_source=notifications&email_token=ADMGY3TKE7CVXYINMCYXKXTQ53SKPA5CNFSM4KHBNE7KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IGJ7HGQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMGY3WULESR5J4FF4OTQXDQ53SKPANCNFSM4KHBNE7A>.

[haarp]

It actually isn't an off-by-one error, I just used 99 and 100 as an example. This issue also presents itself when toggling between e.g. 60 and 100.

[rockowitz]

That's a different issue.  Some monitors will change a value, but still return the old value. Others may reply with the new value but in fact show no change. Or there may be a mismatch between the OSD values and the DDC/CI values.   Such, sigh, is the nature of DDC implementations.   See, for example, the description of myDell U3011 monitor <http://www.ddcutil.com/monitor_notes/#dell-u3011> on page Notes on Specific Monitors <http://www.ddcutil.com/monitor_notes/>. It's easier to see what's happening if you use the ddcutil setvcp and getvcp commands than when using the GUI.

…

On 1/15/20 9:13 AM, haarp wrote: It actually isn't an off-by-one error, I just used 99 and 100 as an example. This issue also presents itself when toggling between e.g. 60 and 100. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18?email_source=notifications&email_token=ADMGY3VR2Y2EZCPNTUASFDLQ54KZNA5CNFSM4KHBNE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAOA4A#issuecomment-574677104>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMGY3SY2SXXWCOQWXPACZDQ54KZNANCNFSM4KHBNE7A>.

[haarp]

Cheers, those notes sounds familiar. Looks like DDC is hell of a mess of poorly implemented specs.

Manual tests with ddcutil seem to work fine, unlike doing the same with ddcui. The monitor consistently returns the correct value when switching back and forth.

> ddcutil -b 9 setvcp 1a 100; ddcutil -b 9 getvcp 1a
VCP code 0x1a (Video gain: Blue              ): current value =   100, max value =   100
> ddcutil -b 9 setvcp 1a 90; ddcutil -b 9 getvcp 1a
VCP code 0x1a (Video gain: Blue              ): current value =    90, max value =   100

This needs around two seconds to run tho, so I suspect that either the additional delay gives the monitor time to propagate the correct value, or that ddcutil does someone additional scanning/initialization that makes the monitor return to sanity.

[rockowitz]

On 1/15/20 9:59 AM, haarp wrote: Cheers, those notes sounds familiar. Looks like DDC is hell of a mess of poorly implemented specs.

Poor implementations, and alternative interpretations of the specs. There's a lot of code in ddcutil to handle these variations.  For example, the spec clearly states that when replying to a getvcp request for a normal (i.e. non-table) feature, the supported/unsupported feature bit should be set.  Some monitors instead return a DDC Null Message for unsupported features.  And others just rely on all value bytes being 0.  Recent LG ultrawide monitors seem to be problematic.  Diagnosing these issues from afar is difficult, which is why the environment and interrogate commands have steadily grown. These deviations from spec are more noticeable in the GUI, which relies on much more state being preserved.

Manual tests with ddcutil seem to work fine, unlike doing the same with ddcui. The monitor consistently returns the correct value when switching back and forth. |> ddcutil -b 9 setvcp 1a 100; ddcutil -b 9 getvcp 1a VCP code 0x1a (Video gain: Blue ): current value = 100, max value = 100 > ddcutil -b 9 setvcp 1a 90; ddcutil -b 9 getvcp 1a VCP code 0x1a (Video gain: Blue ): current value = 90, max value = 100 | This needs around two seconds to run tho, so I suspect that either the additional delay gives the monitor time to propagate the correct value, or that ddcutil does someone additional scanning/initialization that makes the monitor return to sanity.

That is a very interesting observation.  There's a lot of initialization that occurs at the start of each ddcutil execution, but which only occurs once at library startup time.  I'll see if I can come up with a reproducible case here. Thanks for the detailed questions and comments. Sanford

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18?email_source=notifications&email_token=ADMGY3VJTKRT2DNKL3TTWKDQ54QD3A5CNFSM4KHBNE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJATAYY#issuecomment-574697571>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMGY3UPDGOJ4HQOT5364XDQ54QD3ANCNFSM4KHBNE7A>.