> Note that after using this for 15 days now, I still occasionally (say 1 in > 10 times?) get a flash of the unlocked screen content on resume, followed > by the XScreenSaver password dialog. Unclear to me what is going on here > other than "random scheduling races" but that's precisely what this > inhibitor mechanism is supposed to avoid, so hmm, go figure?!
... (more hypothesis) this is indeed a race, between X actually committing the result of "xscreensaver-command -lock" to the hardware and systemd suspending the system. Confirmed-ish by adding the "traditional workaround for all distributed systems problems", namely sleep(1) on our suspend path, works for me, so I've committed that change to GitHub for now. Jamie, if there is a way to sync on the X server actually completing its work, then we could do that instead. Martin
