GNOME Bugzilla – Bug 619773
not properly handling monitor reconfiguration changes
Last modified: 2010-06-21 18:46:37 UTC
Turns out we still aren't properly handling monitor reconfiguration events. See downstream report https://bugzilla.redhat.com/show_bug.cgi?id=594696 The issue comes down to a few things. * When a monitor reconfiguration event occurs between the time we spawn a dialog process and the time a dialog window is mapped and its window id is communicated to the daemon we don't properly cancel the current unlock request. * The present unlock request cancellation code is not symmetric/consistent with the unlock request code. In other words we aren't properly resetting state.
Created attachment 162061 [details] [review] patch
The reproduceable test case: 1. boot system docked. 2. Log-in 3. sleep system 4. Undock system 5. Wake system 6. Sleep system 7. Dock system 8. wake system 9. once screen-saver prompts for password, notice how screensaver lock doesn't respond to keyboard / mouse input.
It's a little hard to get a feel for the "guts" of the patch just reading through it because there are some clean ups mixed in, so I'll do a deeper dive later. One thing I've noticed, just looking at the patch out of context is there previously was a call to remove_watchdog_timer which wasn't shuffled around anywhere. Was it superfluous before? Is it needed now? Anyway, will look deeper later.
The inconsistency of the dialog up and down handling is partly a result of the asymmetric handling of the events. So it is clean up but also a real fix. For example, when a display was added the state of the window that had a dialog up was not reset at all: background not cleared, etc. It seems to me the watchdog_timer thing wasn't handled correctly by the previous set of patches.