User Defined Feature enhancements/documentation and questions about ddcutil HOT 5 OPEN

The file name is quite precisely defined. The mfg-id portion of the file name is exactly the 3 character manufacturer code as specified in the EDID. The product-code is an unsigned integer (16 bit) as specified in the EDID. The model name is that given in the EDID, with non-alphanumeric characters replaced by underscores. The latter transformation could have been better documented. For verbose output of capabilities, getvcp, setvcp, dumpvcp, and probe, the fully qualified name of the feature definition file is reported (if it is found), or the simple name is reported (if it is not found).

I have updated section User Defined Features of the online documentation to more clearly document the above. In addition, with the latest changes to branch 2.1.5-dev, detect --verbose also reports the name of the feature definition file.

from ddcutil.

Added a new NC subtype XNC (extended non-continuous, symbolic constant DDCA_EXTENDED_NC).

In common with SNC, XNC regards the SL byte as having a list of valid values. However, it also regards the SH byte as significant. While there are no features with this subtype automatically known to ddcutil from the Monitor Control Command Set),, it can be specified as an attribute in a user defined features file.

For example, given the following .mccs file:

MFG_ID       SAM
MODEL        U32H75x
PRODUCT_CODE 3586
MCCS_VERSION 2.1
FEATURE_CODE 60 Input Source
  ATTRS XNC RW
  VALUE x05 HDMI-1
  VALUE x06 HDMI-2
  VALUE x0f DisplayPort

Given a value with SH=0x00, SL=0x05,
Normal output: VCP code 0x60 (Input Source ): HDMI-1 (sl=0x05), sh=0x00
Terse output: VCP 60 SNC x00 x05

Input: specify a two byte hex value, e.g ddcutil setvcp 60 x0105

Shared library IO is performed in the normal way using ddca_get_non_table_vcp_value() and ddca_set_non_table_vcp_value()

from ddcutil.

Two conflicting issues

Now a more specific UDF question/suggestion/issue.

Background

But some background first. I had a issue reported with vdu_controls when used with ddcutil-service. A getvcp on an SNC value was coming back as 0x0f01 instead of 0x0001 (digitaltrails/ddcutil-service#21). I figured that the SNC high-byte might sometimes contain junk and needed masking off. I implemented that solution generally in ddcutil-service 1.0.3. But then a different user raised another issue saying the ddcutil-service 1.0.3 had stopped returning the high byte - they had an SNC field where the high-byte had significance. So it seems a manufacturer did not obey the requirement that an SNC be one byte (digitaltrails/vdu_controls#85).

Could UDF have a role to play in resolving the second issue?

I considered whether the second problem could be fixed by defining an user defined feature that redefined the SNC to a CNC, then ddcutil-service would not mask the high-byte, problem solved. But I see that that UDF only supports NC, and adding a two byte NC is flagged as an error. Should mccs files allow for redeclaring a value as CNC?

What I've actually done

Anyway, what I've done in the meantime is to provide ddcutil-service with a flag to return the raw unmasked value. Vdu_controls uses that flag to get the entire value from the service, and it makes it own decision on what to do with the high byte. It would normally discard it (covers the first issue), but if the any values in the capabilities-override exceeds one-byte, it internally promotes the SNC to CNC, so the high-byte gets retained (covers the second issue).

from ddcutil.

Re the meaningful value in the SH byte in what otherwise is a SNC feature, the simplest extension would be to allow SNC and CNC as valid attributes, with SNC being a synonym for the currently valid NC. ddcutil and ddcui would just report such features as 2 byte hex values, without any interpretation.

A more complete solution would be to have an extended SNC type, say "ESNC" what would allow for specific values in SL with an arbitrary value in SH, or perhaps even a list of specific values in SH. This would require creating a new interpretation function for ddcutil, and a new widget for ddcui. The latter might prove tricky given the space constraints.

I'm open to implementing the SNC/CNC extension at this time and seeing how it works out.

from ddcutil.

I'm open to implementing the SNC/CNC extension at this time and seeing how it works out.

Being able to promote SNC up to CNC would solve such problems with no change to existing clients, so it seems to be a good option. Given this is probably quite a rare situation, this seems quite a minimal way of dealing with it.

I probably wouldn't have gone to the effort to change ddcutil-service and vdu_controls if this was already an option. With hindsight I wonder if I should have given vdu_controls some ability to create/manage UDF files.

from ddcutil.