Value inconsistencies between decimal and binary

[ashirviskas]

I'm a super new user, so I'm not sure if it is a bug or some convention, but either way it is super confusing.

When I list features with ddcutil capabilities I get:

Model: FI27Q
MCCS version: 2.0
...
   Feature: 60 (Input Source)
      Values:
         11: HDMI-1
         12: HDMI-2
         0f: DisplayPort-1

However, if I try to ddcutil setvcp 60 0f I get:

Not a number: "0f"
Invalid VCP value: 0f

After only a few tries I figured that I have to turn these numbers from hex into decimal to be able to properly set this value and use 17, 18 and 15 instead of 11, 12 and 0f. If it wasn't for 0f that gave it away, I might have been confused for a few more minutes. Is there any reason there is this inconsistency?

[digitaltrails]

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.

[rockowitz]

@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,