Future Enhancements

[rockowitz]

Possible future enhancements for 2.2.4 and beyond

• basic Python API
• update www.ddcutil.com, incorporate information in release notes, reorganize
• read PCI and USB ids from local distribution files instead of hard coded (done, 2.2.2)
• robust sample application using libddcutil, replace current trivial sample code
• automated testing
• revise interrogate command
• increase internal use of Error_Info struct in place of return codes to report errors
• optionally emit command output in yaml or json (option --yaml, -json) for use by script writers. Initially implement for getvcp, setvcp, detect
• list specific features on dumpvcp
• when using option --edid, recognize values in Base64 as well as a 256 character hex string. Include the Base64 representation in the output of ddcutil --verbose
• recognize display selection options on detect
• implement watch mode kscreen if running on KDE. The mode would rely on the kscreen dbus service.
• ddcutil CLI command that watches for display changes and returns when one is detected (for use in scripts)
• because of reports of bricked monitors, disable all setvcp operations of Xaomi monitors instead of just issuing a warning in ddcutil detect, perhaps with an option --allow-setvcp to override the block
• unify base and utility layer functions that write normal messages and trace messages to the terminal, system log, or a log file
• reduce default getvcp output field size from 5 to 3 characters

[codayon]

The output for ddcutil getvcp looks a bit long because of the extra spaces. When I first ran the command I thought something was wrong because of that ):

VCP code 0x10 (Brightness                    ): current value =    40, max value =   100

[rockowitz]

getvcp output uses large field sizes for feature names and values so that multi-feature output aligns.

Continuous features like brightness are 2 byte values. Hence 5 characters is allowd for the values.

In practice I've never seen values that require 5 characters. (This highest value I've seen for brightness is 320,) so the default field size could be reduced to 3 characters and the output would generally align. I'm open to making this change if there are additional people who find the current output format problematic. However, the size of the feature name field needs to remain large so that output is easily visually scanned.

[codayon]

I'm a web developer, I was thinking if the spaces between contents can change dynamically based on content width. But, seems like things work differently in here. Never mind, thanks for the response!