Apply scheduled preset when monitor goes back on #96
Comments
|
What are the circumstances: What version of vdu_controls (listed in the About dialog)? Is vdu_controls being used with ddcutil-service or just the ddcutil command? Which of the following describes your situation?
Case 1 is covered if vdu_controls is ddcutil-service, the preset that was last due will be restored. If not using the service, pressing the refresh button also restores the preset that was last due. Case 2 was covered by looping the attempt to restore until it succeeds. This seems to still be working for a brief test just now. Possibly there may issues if the repeat drags on across midnight (local time), when the schedule updates (but I think that was tested). But changes to the handling of concurrency may also give room for new bugs. Definitely forgot about 3, that would depend on what Qt does about its timer jobs when the PC wakes up. Hibernate/suspend is not something I use, so I hadn't even thought about it. If the Qt timers don't cover it, I should probably reimplement with code that checks if a preset is due or overdue and fires it. Case 4 is similar to case one, on startup the preset that was last due will be restored. This code may be potentially be repurposed to cover more cases, such as case 3. |
|
To be honest I don't quite understand these case descriptions. I have 2.1.1. I was using ddcutil command but installed ddcutil-service today. Does not seem to have made a difference. In fact, I just logged back in to type this answer and it did not apply my "night" preset as it should. Weirdly enough, it even went back to "noon" preset even though it had correctly applied earlier my "evening" preset (as monitor was on at that moment). |
|
OK, so this is more like case 2. Presumably the screen saver is sending the monitors into power saving, which is somewhat similar to turning them off (but not quite). Anyway, I'm not seeing a similar behaviour. I have seen wacky behaviour if the system locale (e.g. NZ, AU, CN) and GPS coordinates don't match, but then the solar elevation chart would also look wrong. What happens if you restart vdu_controls - does it kick in the right preset? Perhaps consult your logs, presumably the systemd journal or stdout/stderr depending on how you are running vdu_controls or whether you have enabled the syslog logging. Does the log contains any errors of interest. In my case, if ddcutil-service is running, within a minute or so of powering up a monitor, I would expect to see: And shortly after, vdu_controls should log: You could tar/zip up the logs and attach them here (remove anything sensitive logged by other processes). Plus tar/zip up and attach your config directory. |
|
|
If I restart vdu_controls then the right preset always kicks in. I'll check the logs tonight. |
|
Here are some logs for anything "vdu" or "ddcutil". |
|
A few thoughts/questions:
|
|
For the "initialization-preset", well I really don't understand what it does. I added it because in a recent version I was proposed to create it and I thought that maybe it would help with my issue. |
|
Yes, delete it. If the From your log it looks like vdu_controls "thinks" it successfully already restored Sunset at 17:54. If the monitor was actually not on at that time, that would probably mean the monitor was still accepting, but not applying commands. For my own monitors, if they were off at 17:54, there would be an error and vdu_controls would keep trying until eventually succeeding at 18:12:01. So it looks like I might need to add some code to handle such a case. The problem is that not knowing whether Sunset has been properly restored means vdu_controls may keep restoring it each time the monitor wakes, and this may tread on any manual changes the user makes in between the sleeps. |
|
Could we sample your logs now that the initialization_preset has been removed. Perhaps turn on the debugging setting to get more info. It's quite difficult to understand how a set_vcp can succeed if the monitor is off. Part of the process of restoring a Preset is to perform get_vcp calls to see if it has set all the required values have been met. The restoration should error if the monitor setting does not stick. But if the monitor is behaving badly, I guess anything is possible. I may have to add a special option, 'hard-dpms', that would treat a DPMS event as requiring a total reconfiguration - which is what happens when more monitors are hot-plugged. But this may not work if I'm misunderstanding the problem. |
|
Logs since late last night from the moment I activated debug setting. I just logged in for the first time this morning few minutes ago (10:42) and the correct setting did apply. |
|
In the last few days it seemed that everything was finally working perfectly. Here are the logs for when I turned one the monitor few minutes ago. |
|
What time was the preset scheduled to change? What was logged around the time of the change? |
|
Two presets should have applied: one at 7:27 (1° East) and one at 9:39 (21° East). |
Was the machine powered off prior to, or at, these times? Was there any vdu_controls logging prior to oct 23 12:52:23? There may be a bug in identifying the preset that should be active at this time, but I'm not yet sure. I need to do more analysis and testing. But I'm not sure it explains the situation if the machine was on the whole time. The existing code assumes that that it can trust its internal view of what has been changed in each VDU. It may be that this is not true. So as a second line of approach, I may look to reinitialize schedule state when DPMS state changes. I need to be a bit careful, I don't want to repeat the mistakes of KDE6 where they are doing unexpected brightness changes due to assuming they know the state of the VDUs. |
No.
They were at 1:46 when I suppose "screensaver" (shutting off the monitor) kicked in: |
|
That's weird, I would have expected to see schedule activation info messages at the set times. I would also have expected to info message about the scheduling of presets for the new day just after midnight. I wonder if the Qt QTimer mechanism, or associated threads, can fail? Maybe I need to add code to check this somehow. Platform issue? What Linux distro are you running? Presumably you're running the distro's KDE and Qt. |
|
Ubuntu 24.10 (Gnome) |
|
I leaning toward treating the symptoms: assume threading or threading-coding errors exist, and should be automatically recovered from. Question: after your system enters this state, but is no longer sleeping, if you do nothing, do later schedule presets get activated on time? The reason I ask, is that would indicate that the entire schedule isn't working. In which case, not only do I have to activate the expected preset, but I have to reinitialise the entire schedule (which is in some ways is simpler). |
|
Note to self: on DPMS wake, check the schedule times of presets, if they are not in the current day, then reschedule them all. The existing scheduling code will then also activate the appropriate preset. (This will be more economical that doing the scheduling regardless.) Suspicion is that the daily reschedule is not always occuring. |
More notes: Rewrite the single-shot QTimer change of day code. Use a subthread that periodically wakes up and checks for an out of date schedule or missing schedule. This should work across hibernate or anything else that keeps the app from firing a timer. During scheduling, also restore the preset that should be active at that time (if necessary). This is a bit uglier: the app will keep waking up. The app is already waking up in the Qt event-loop, maybe we could piggyback off the Qt event-loop and not have another thread. (Is it possible something can lock out event-loop activity?) |
Yesterday, when the preset was not correctly applied on waking up the computer I had to manually apply the correct preset but I noticed that later in the day the subsequent presets also did not get applied too. I had to completely close vdu_controls app and restart it. This morning the presets correctly got applied. Logs since October 23 midnight: |
Kind of good news. My suspicions about maybe the schedule not being renewed at start-of-day seem to be correct. Which is just as well because I've begun a re-write of how the schedule gets renewed. Thanks for the log. It looks like nothing was logged prior to 1:46, the schedule renews at around midnight. Also no schedule events were logged. [EDIT - I see the logs roll into a new day - I will keep reading... could be very interesting.] I'm still coding and testing, I may push up a new version to truck later today or tomorrow. It will check what Preset should be active on any DPMS wakeup. It will also change how start-of-day is detected to something like what I described in my notes above. What I'm still pondering, is how much to trust QTimer events? I think repeating timers seem trustworthy. I may add more boilerplate to check that the timer is actually running. The question is where/how to I detect that the timers have failed (what can I trust to run). Perhaps if the user presses refresh or on DPMS wakeup. |
|
This is interesting: The above scheduling didn't schedule anything, where as the one below did: That's probably a bug in my code. |
|
Even though I had always disabled power management so that my computer does not go to sleep, I just learned by experiencing it that newest Ubuntu and or Gnome do enable some power management... |
The timer is firing 1 second early, which means it will schedule for the wrong day. All Presets will be ineligible because there schedule time has already past. The exact time might be a bit random, so some days this would happen at 00:00:?? other days at 23:59:??. So perhaps I can trust the timers to fire, but not exactly on time. There is an option to make them more precise, but in this instance it's probably just easier/safer to do some kind of rounding-up. OK - reverse back some of the mornings work. I'll try and rig up a test to confirm the above. |
I will probably add a test somewhere that checks that the schedule is in place. That will be simpler than trusting a re-write of the current QTimer. I need to check if QTimers survive hibernate - I just read a suggestion that single-shot timers may survive, and currently this is a single shot timer that is replaced each day. |
…fallback to last applicable preset from the previous day. Output more info about the decision-making.
…dd more info so we can tell what decisions were made.
|
76cc2fe will activate the preset that should be active now, or there isn't one, the last one that should have been active yesterday. 4cee91a the schedule-update now happens at 30 seconds after midnight. This hasn't been tested on a real end-of-day rollover. Might do something more precise, but this is a quick fix for now. Still pondering what to do about hibernate. |
…during the polar summer (not tested).
…g to ensure only one scheduling update can run at a time.
|
Preset correctly applied today. |
…ervative with other changes/checks coded for the issue. Want to avoid interfering with use of the manual controls.
Thanks for the new log. It looks like the new code is working, the timer again fired at 23:59:59 and the code corrected to the following day. I've reversed out some of the other changes so as not to interfere with changes made manually by the user. But I left in a sanity check, on DPMS wake, if there is no schedule and there should be, then rescheduling is performed and the appropriate Preset is restored. |
|
Your Presets appear to have French names. Are you using the translations enabled setting to pick up the the translation via locale settings? When enabled the LC_ALL and LANGUAGE environment variables determine the translation (providing the translations are installed). The reason I ask is that in the last release I stopped updating the translations. The translations are from DeepL and google-translate. No one has complained about their phrasing or grammer, so I assumed no one was using them. I'm happy to update them, but only if they are in use. |
|
They have French names because I labelled them as so since I speak French. |
I guessed that. I thought I'd ask if you are also using the setting translations enabled? Because:
|
|
No, not using it (and had not noticed it anyway). |
OK, thanks. I'll continue to not update the translations until someone complains, or I run out of things to do on a rainy day. |
|
Preset did NOT get correctly applied today. |
|
It looks like the timer did not trigger at midnight. I wonder how that could happen. It seems like there is more than one issue at play. Fixing the 23:59:59 aspect of the problem has only addressed one of them. Back to: maybe the system was in some kind of sleep/hibernate; or maybe I can't trust this timer (which raises the issue of what can I trust). Are you running the latest code? I added check_preset_schedule() call at Line 7710 in 42c42e0 I thought it would trigger on the DPMS wake, but it hasn't logged anything. |
|
Oh, I had not noticed you made more changes yesterday. I was still on version of two days ago. |
Sorry, I probably should have noted it here. |
|
According to this answer: If vdu_controls is ever put into hibernation, any long run qtimer will be delayed by the amount of time slept. A sleep of n ms becomes n + h where h is the amount of time spent hibernating. I need to stop using qtimers for the daily re-scheduling and for the time of solar activated changes. I need to implement a polling scheduler that wakes every minute or so and checks if it's past time to trigger events in an event queue. Some events need to override other events in the queue, for example, only the most recently due solar elevation change should apply. The easiest way to implement this would be to mirror the qtimer interface so the existing code doesn't require refactoring. |
|
So far so good. (still on commit 42c42e0) |
Please leave it open, I have a bit more work to do. I've done some searching on how hibernate affects QTimers (see #96 (comment)). Basically QtTimers are delayed by the length of each hibernate and will trigger late. This creates issues for those using ddcutil-command (rather than ddcutil-service) - because there is no DPMS wake event possible when using ddcutil-command. I'm going to reimplement the scheduler using a loop and short-sleep approach so I can trigger when HH:MM:SS match (where as the QTimers trigger after ms delays). So, for now, you're good to go with ddcutil-service and the DPMS-wake event, but I will rework to cover those using ddcutil-command. |
|
Ok. |
I hope to make scheduling work well for both. But it's worth documenting that ddcutil-service is the only one that reacts to DPMS-Wake - will do so. |
|
I've reimplemented the Preset scheduler. The new code wakes every minute and checks the YYYY/MM/DD HH:MM:SS datetime. This replaces the Qtimer based implementation that scheduled presets in milliseconds, which broke if hibernation stopped the QTimer millisecond countdown. All the previous fixes and complexities had either been removed or implemented in a different way. When it wakes periodically, or after PC power-up, or after PC wake-up, the behaviour of the scheduler is to always find and restore the most recently overdue preset based on wallclock time. If there is not yet an overdue preset, the scheduler finds the last preset from the previous day. (By overdue I mean a Preset scheduled for a time less than or equal to now). This new implementation does not rely on DPMS events to detect/fix hibernation delays. It just checks the wall-clock every minute, so it will automatically recover after hibernation (or power-outage or vdu_controls not running). |
|
The new Prest scheduler has now past all the tests I could think to throw at it. Scheduling events are now applied according to the current wall-clock minute. If DPMS events are available, events may also trigger immediately if they are overdue (so there is no delay waiting for the next minute to tick over). |
Hi,
I tested this for a couple days and it seems that if a monitor was off at the time of a scheduled preset then when the monitor goes back on the appropriate preset will not be applied.
I don't know if it's a bug or just not a feature currently implemented but that would definitely be a nice addition so to never have to manually apply a preset.
The text was updated successfully, but these errors were encountered: