display_control: Make display_name include monitor name, serial number, etc #56
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi; this pull request adds information to the display_name of each monitor, as I suggested in #54 .
Currently the display_name() function uses only the 'id' field of the ddc_hi::DisplayInfo struct, plus a possible numeric suffix to disambiguate otherwise-identical display names. At least on Linux, this leaves a lot of useful information out of the display name, because for the i2c-dev backend to ddc_hi the 'id' string is just the decimal representation of the (major,minor) of the i2c device node (e.g., '22789' == 0x5905 == device (59,05) == /dev/i2c-5).
There is usually more usefully identifying information in the DisplayInfo structure, including the 3-character manufacturer ID, the model name, and the monitor serial number. The pullreq adds this information to 'id' if it is present. The result is that instead of logging like
you get
and you can also write monitor_id config file settings that match against the monitor model or serial number.
I guess in theory if users have config files with very short strings in their monitor_id settings then adding the extra info might cause them to match on monitors that previously didn't match; but this seems fairly unlikely in practice to me.
I'm not sure what Windows and OSX monitor ID strings look like, but adding the extra info doesn't seem like it could hurt.
NB: There are a lot of ways you could write the string-assembly in this function (eg heavy use of iterators); as somebody fairly new to rust I went for something that seemed to me fairly straightforward and easy to understand, and more-or-less in line with how the previous version of the function did things. Let me know if you'd like me to have a go at writing this in a different style.