Value inconsistencies between decimal and binary about ddcutil HOT 2 OPEN

Yeah, it's a bit inconsistent, but it's possible to make it consistent by using standard hex prefixes, try:

ddcutil setvcp 0x60 0x0f

If you think about a human just wanting to set brightness, the following works with little need for explanation:

ddcutil setvcp 10 100 

It's mainly when you get into non-continuous values that the confusion arises.

I suspect we're stuck with this, or scripts and applications that interact with ddcutil will break. For my own scripts I've now elected to use hex prefixing all the time.

from ddcutil.

@ashirviskas I agree, its not immediately clear whether the parsed capabilities values for non-continuous features are integer or hex. That there's no leading "x" or "0x" seemed natural when the capabilities command was coded, very early in ddcutil development. given that the unparsed capabilities string returned by the monitor just contains 2 byte hex values. That decision has not worn well. By contrast vcpinfo --verbose, a much later command, reports non-continuous values with a leading "0x". And getvcp --verbose reports the raw bytes with a leading "0x".

It would be good to consistently use either leading "x' or "0x" when reporting hex values. Unfortunately, as @digitaltrails notes, there are screen-scraping applications that parse output that was meant for human consumption. So such changes are not to be made lightly.

Note that when a value is specified by the user, if it begins with "x", "X", "0x" or "0X" it is treated as hexadecimal, otherwise it is an integer. The major exception to this rule is VCP feature code values are always interpreted as hex, whether or not there is a leading hex specifier. The reason for this is that DDC documentation always specifies features identifiers using their hex values. It would be unnatural to refer to feature x 60 (Input Source) as feature 96,

from ddcutil.