User Defined Feature enhancements/documentation and questions

[digitaltrails]

I was attempting to use a User Defined Feature to work around a problem VDU.

First some general comments on the UDF's.

It would be good if filename was more easily derived or more exactly defined. I had to guess a bit and only got it right by trial and error, dtrace of open, and a fortuitous error in the file content that caused ddcutil to out Error(s) processing monitor definition file: blah.mccs.

So the file name is constructed from the output of ddcutil detect as follows:

1. Split the Mfg Id by spaces and retain the first three letter acronym only.
2. Trim the Model and substitute "_" for each internal space.
3. Split the product code by spaces and retain the first (non-hex) part.
4. Combine 1, 2, and 3 with hyphens (-) and suffix with the ".mccs" file type.

More formally defined in awk:

ddcutil detect | awk -F: '
   $1 ~ /Mfg id/ { split($2, parts, " "); mfg_id=parts[1];}
   $1 ~ /Model/ { model=$2;  gsub(/^ +/, "", model) gsub(" ", "_", model);}
   $1 ~ /Product code/ {split($2, parts, " "); product_code=parts[1];
                        printf("%s-%s-%s.mccs\n", mfg_id, model, product_code);}
   '

Then use the same extracted part values at the top of the mccs file.

Suggestions

• It would be quite nice if ddcutil could print out the required filenames (perhaps there is already an option where it does this).
• It might be nice if there was an option to create a starter file with just the header. I guess the above awk script could be repurposed for that.

[digitaltrails]

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).

[rockowitz]

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.

[rockowitz]

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.

[digitaltrails]

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.