Vdu Controls Versions Save

VDU controls - a control panel for monitor brightness/contrast/...

v1.10.0

1 year ago

v1.10 Changes

  • Added hardware lux metering options:
    • GY30/BH1750 Lux sensor + Arduino feed,
    • UNIX-fifo feed,
    • executable-script feed:
      • sample scripts are included for using a webcam to produce approximate lux values:
        • /usr/share/vdu_controls/sample-scripts/lux-from-webcam.bash
        • /usr/share/vdu_controls/sample-scripts/lux-from-webcam.py
  • Lux-to-brightness profiles for automatic brightness adjustment:
    • Per VDU profile chart.
    • Lux-level attachment to Presets for automatic Preset activation.
  • Improved Preset Dialog:
    • Solar-elevation chart - added drag-to-change, click-to-delete, and a visual representation of angle of elevation.
    • Replaced the transition combo-box with a drop-down checkbox options to allow for combinations of options.
    • Adding Save, Revert buttons to present a more conventional UI layout.
  • Added an option to transition smoothly on UNIX signal.
  • Added settings to globally disable weather and globally disable solar-elevation-scheduling.
  • Cleanup of thread handling - clarification of GUI/non-GUI thread operations.
  • Reduced logging and eliminated popup dialogs when monitors are suspended or powered off.

The new Light-Meter Dialog

There is a new Global-Setting Lux Metering Enabled, if set, the following dialog will be available from the normal Context-Menu:

lux-profiles

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.

v1.9.2

1 year ago

Optional Smooth Value Transitions for presets (issue #29) :

  • The Presets Dialog now includes an option to set a Preset to Transition Smoothly.
  • The tray icon, main panel, and Preset Dialog indicate when a smooth transition is in progress.
  • Transitions are performed by a non-GUI thread, the GUI remains accessible during smooth transitions.
  • A smooth transition can be interrupted by moving the controls being transitioned or invoking a different preset.

The following screenshot shows the additions to the Presets Dialog:

Screenshot_20230223_144147

  1. Transition Smoothly selector:
    • Never transition smoothly,
    • On schedule according to solar elevation,
    • Always by elevation or manual selection on the context menu.
  2. Transition step seconds between stepping the controls.
  3. Transition summary type, step-seconds column/button, the button can be used to manually invoke a transition. ▹Transition On schedule ▸Transition Always

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

1 year ago

V1.9.1 contains a collection of minor improvements and fixes:

  • The text input to right of slider controls, such as brightness and contrast, have been replaced with a SpinBox with up/down arrows.
  • The main panel progress-bar spinner will now also display during preset-activation (in addition to displaying during refresh).
  • Refresh and preset controls now lock during refresh and preset-activation (to prevent conflicting actions).
  • The context menu and hamburger menu are now available during refresh (a subset of actions is available, such as help and about).
  • The 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.
  • The VDU 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.
  • Build changes for submission to OpenSUSE Development and Factory by @malcolmlewis.
  • The thread handling and error handling has been cleaned up.

Full Changelog: https://github.com/digitaltrails/vdu_controls/compare/v1.9.0...v1.9.1

v1.9.0

1 year ago

I've made some significant performance improvements prompted by issues, tests, and fixes contributed by @denilsonsa.

  • Bug fixes and speedy performance improvements:
    • Speed up initialization and refresh by combining multiple ddcutil getvcp requests;
    • Stop executing a getvcp precheck before each setvcp.
    • Fix repeat-initialisation bug in Context-Menu Refresh.
    • Fix Settings Dialog text field validation, some errors were invisibly ignored.
    • Fix Settings Dialog Settings Enable VCP Codes, they had stopped working.
    • Fix the monitor specific sleep multipliers, they were not always being used.
    • Treat all monitor detection situations as needing time to stabilise (helps in disconnect situations).
    • Fix event handling so that tablet+pen input works on the main window.
    • Default to a sleep-multiplier of 1.0 to support a wider range of monitors out of the box.
  • V1.9.0 drops support for converting from v1.6.* config and preset files. To convert from v1.6.* and earlier versions, follow these steps to download and run v1.8.3:
     % 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.
  • See v1.8.2 release notes for further details on the All Weather Edition.

v1.8.3

1 year ago

Fixed a couple of bugs:

  1. If the network or weather site was unavailable, vdu_controls might terminate.
  2. The python build setup.cfg needed updating, it was causing python -m build --wheel --no-isolation to fail.

See v1.8.2 release notes for further details on the All weather edition.

v1.8.2

1 year ago

Weather restrictions

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:

Screenshot_20221127_weather

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.

Improved solar elevation trigger behaviour when monitors are offline

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.

Language translations

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)

v1.8.1

1 year ago

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.

v1.8.0

1 year ago

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.

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

v1.7.2

1 year ago

Two improvements addressing issues #26 and #27.

  1. The Presets Dialog now includes arrow keys that can alter order in which the presets appear in the Prest sub-menu. For example you could arrange your presets from brightest to darkest.
  2. When no monitors are detected, vdu_controls will no longer exit. This improves the behaviour for laptops with external monitors that may be absent or powered off. The old no-monitors error-popup will now only appear if warnings are enabled.

Here is a screenshot illustrating the changes:

Screenshot_20221007_163046

v1.7.1

1 year ago

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