After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 619773 - not properly handling monitor reconfiguration changes
not properly handling monitor reconfiguration changes
Status: RESOLVED FIXED
Product: gnome-screensaver
Classification: Deprecated
Component: daemon
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-screensaver maintainers
gnome-screensaver maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-27 00:17 UTC by William Jon McCann
Modified: 2010-06-21 18:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (14.96 KB, patch)
2010-05-27 00:19 UTC, William Jon McCann
committed Details | Review

Description William Jon McCann 2010-05-27 00:17:22 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.
Comment 1 William Jon McCann 2010-05-27 00:19:03 UTC
Created attachment 162061 [details] [review]
patch
Comment 2 William Jon McCann 2010-05-28 16:48:03 UTC
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.
Comment 3 Ray Strode [halfline] 2010-06-01 17:19:21 UTC
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.
Comment 4 William Jon McCann 2010-06-02 17:16:25 UTC
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.