Debugging screen locking problems (Security)
There is a large quantity of screen locking bugs with many causes, and they are not getting fixed. (See the list on: https:/
This blueprint is to create a "DebuggingScree
Blueprint information
- Status:
- Complete
- Approver:
- Robbie Williamson
- Priority:
- Essential
- Drafter:
- Marc Deslauriers
- Direction:
- Approved
- Assignee:
- Marc Deslauriers
- Definition:
- Approved
- Series goal:
- Accepted for lucid
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Kees Cook
- Completed by
- Marc Deslauriers
Whiteboard
Work items:
create screen-locking PPA: DONE
create debugging flowchart: DONE
debug screen-locking issues with hamster-applet: DONE
release hamster-applet update: DONE
debug screen-locking issues with totem: DONE
release gnome-screensaver update for totem issue: DONE
debug screen-locking issues with gnome-screensaver activation: DONE
release gnome-screensaver update for activation: DONE
create new apport hooks for gnome-screensaver: DONE
backport apport hooks to older releases in screen-locking PPA: POSTPONED
create wiki page: DONE
describe how screensaver/
add further debugging tips to wiki page: DONE
add known issues to wiki page: DONE
add link to wiki page to all screen locking bugs: DONE
review old bugs for the common Karmic failure (suspend-
Gobby notes:
= DebuggingScreen
* Which window manager are you using?
* Metacity/Gnome
* gnome-power-manager
* configuration for locking in various modes
* Hibernate
* Suspend
* Idleness
* Default lock behaviors (gconf:
* lid-close, key event, g-p-m, g-ss lock, g-p-m waits for g-ss reply, devkit-power suspend
* what happens if g-ss fails or does not reply?
* there is a bug prior to Karmic where waiting for the lock did not happen
* Karmic also uses "throttle" vs lock
* "follow screen saver locking setting in gnome-screensaver for suspend/hibernate" setting
* if hal is dead, no screen locking seems to happen at all?
* xsession-errors?
* enable debug mode?
* gnome-screensaver
* idle failure (ie, didn't lock)
* context menu is open
* VM window has stolen context?
* gnome-kerying dialog
* did some other window say it is the most important via the X protocol?
* is it running?
* did it respawn? (got lost on dbus)
* Is a hack is configured?
* it is the responsibility of the hack to cover the screen.
* try blanking the screen instead of using a hack and see if it helps
* gconf key for hack/blank/random?
* xsession-errors?
* User-switcher
* indicator-session, g-ss lock, g-ss wait, ck new-session (gdm in lucid)
* what happens on g-ss failure?
* needs to log errors
* Compiz/Gnome
* driver redraws desktop before screensaver layer
* KDE
* Xfce
