-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User Defined Feature enhancements/documentation and questions #403
Comments
Two conflicting issuesNow a more specific UDF question/suggestion/issue. BackgroundBut 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 doneAnyway, 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). |
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. |
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. |
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. |
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:
Given a value with SH=0x00, SL=0x05, 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() |
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:
More formally defined in awk:
Then use the same extracted part values at the top of the mccs file.
Suggestions
The text was updated successfully, but these errors were encountered: