VDU controls - a control panel for monitor brightness/contrast/...
/usr/share/vdu_controls/sample-scripts/lux-from-webcam.bash
/usr/share/vdu_controls/sample-scripts/lux-from-webcam.py
There is a new Global-Setting Lux Metering Enabled, if set, the following dialog will be available from the normal Context-Menu:
Brightness/Lux profiles are constructed by selecting a VDU, and then clicking on the plot area. Details concerning hardware options for light metering can be found in Lux-metering.md.
Optional Smooth Value Transitions for presets (issue #29) :
The following screenshot shows the additions to the Presets Dialog:
Although transition step sleep speed allows the sleep seconds to be set as low as zero seconds, the effective step interval is limited by actual DDC/CI response times. The achievable step interval for a single monitor setup is likely to be is between 1 and 2 seconds per step, and the time increases linearly for each additional monitor.
V1.9.1 contains a collection of minor improvements and fixes:
brightness
and contrast
, have been replaced with a SpinBox with up/down arrows.Settings
save options have been changed to Save
, Discard
, and Cancel
. Cancel
vetoes Close
.Settings
Save-All
will only cause one collective UI refresh, instead of one for each file saved.EDID
128/256 byte identifier is now used internally to ensure the controls operate on the correct monitor. This resolves an issue for desktops with multi-monitors when display numbers are reassigned due to a an active monitor being toggled off.Full Changelog: https://github.com/digitaltrails/vdu_controls/compare/v1.9.0...v1.9.1
I've made some significant performance improvements prompted by issues, tests, and fixes contributed by @denilsonsa.
getvcp
requests;getvcp
precheck before each setvcp
. % wget https://github.com/digitaltrails/vdu_controls/blob/v1.8.3/vdu_controls.py
% python3 vdu_controls.py
Alternatively, start fresh by moving or removing the old configs from $HOME/.config/vdu_controls
.Fixed a couple of bugs:
See v1.8.2 release notes for further details on the All weather edition.
Presets scheduled by solar elevation can be subject to optional weather requirements. Weather requirements will be checked against the weather reported by https://wttr.in.
For example, a preset called Sunny might only activate in good.weather
, where good weather is defined by a list of WWO (https://www.worldweatheronline.com) weather codes:
113 Sunny
116 Partly Cloudy
119 Cloudy
176 Light Showers
The UI for this will look as follows:
By default, there are three possible weather requirements: good
, bad
, and all weather
. Each requirement is defined by a file containing a list of codes, one per line. The three defaults are contained in the files $HOME/.config/vdu_controls/{good,bad,all}.weather
. Additional weather requirements can be created by using a text editor to create further files. The all.weather
file exists primarily as a convenient resource that lists all possible codes.
Because reported current weather conditions may be inaccurate or out of date, it's best to use weather requirements as a coarse measure. Going beyond good and bad may not be very practical. What's possible might depend on you local weather conditions.
To ensure wttr.in
supplies the weather for your location, please ensure that Settings
Location
includes a place-name suffix. The Settings
Location
Detect
button has been enhanced to fill out a place-name for you. Should wttr.in
not recognise a place-name, the place-name can be manually edited to something more suitable. The nearest big city or an airport-code will do, for example: LHR, LAX, JFK. You can use a web browser to test a place-name, for example: https://wttr.in/JFK
When weather requirements are in use, vdu_controls
will check that the coordinates in Settings
Location
are a reasonable match for
those returned from wttr.in
, a warning will be issued if they are more than 200 km (124 miles) apart.
If the place-name is left blank, the wttr.in
server will try to guess you location from your external IP address. The guess may vary due to
the state of the wttr.in
server. It's best to fill out a place-name to ensure stable results.
Solar elevation triggers are now better behaved in the event that monitors are off or suspended. The previous behavior was that as each trigger came due, it would raise a dialog-box stating that the monitor might be offline and ask weather the Preset restoration be retried? If the monitor remained offline for multiple days, additional dialog-boxes would continued to be raised, with no limit on the number of dialog-boxes that might accumulate waiting for a response. Now only the most recent retry dialog-box will remain.
This release includes support for localised language translations. Three bulk AI bulk translations by deepL+google are included: Danish (da_DK), French (fr_FR), and German (de_DE). Because none of the translations have been confirmed to be valid, they won't be used unless you turn on the translations enabled
global setting.
Additionally, in order to engage a translation, your session's LC_ALL, LANG and LANGUAGE have to be correctly setup. Hopefully your desktop environment should have set those for you, if not you can set them manually: for example
LC_ALL=da_DK.UTF-8 LANG=da_DK.UTF-8 LANGUAGE=da_DK python3 vdu_controls.py --translations-enabled
The translation files are XML in Qt .ts
format. You can manually edit and correct them using any text editor. The translations search path is .config/vdu_controls/translations/
and /usr/share/vdu_controls/translations/
.
Please contact me If you'd like to assist by proofreading a language file. I can bulk create a starter file for any language supported by deepL (my AI/bulk translation process is documented at the top of extract_translations.py)
This is a small release to fix next-day preset scheduling, if vdu_controls was left running overnight, the schedule for the next day didn't kick in.
See the v1.8.0 release notes for more info on v1.8.
This is a new-feature release. Preset activation may now be triggered by solar elevation. The idea being to automatically change presets according to the prevailing illuminance, such as dawn or dusk, or the sun rising above the surrounding terrain. The time of which these presets should trigger varies as the seasons change, hence the use of the solar elevation.
To assign a trigger, use the Preset Dialog to set a preset's solar-elevation
. A solar elevation may range from -19 degrees in the eastern sky (morning/ascending) to -19 degrees in the western sky (afternoon/descending), with a maximum nearing 90 degrees at midday.
If a preset has an elevation, it will be triggered each day at a time calculated by using the latitude and longitude specified by in the vdu-controls-globals
location
option.
By choosing an appropriate solar-elevation
a preset may be confined to specific times of the year. For example, a preset with a positive solar elevation will not trigger at mid-winter in the Arctic circle (because the sun never gets that high). Such a preset may always be manually selected regardless of its specified solar elevations.
On any given day, the user may temporarily override any trigger, in which case the trigger is suspended until the following day. For example, a user might choose to disable a trigger intended for the brightest part of the day if the day is particularly dull,
At startup vdu_controls
will restore the most recent preset that would have been triggered for this day (if any). For example, say a user has vdu_controls
set to run at login, and they've also set a preset to trigger at dawn, but they don't actually log in until just after dawn, the overdue dawn preset will be triggered at login.
Two improvements addressing issues #26 and #27.
Here is a screenshot illustrating the changes:
Incorporate fix for signal handling from Mark Lowne (the refactoring for v1.7.0 broke the signal handling).
See also: V1.7.0 Release Notes