Re: Screensaver Solution Discussion
- From: Brian Cameron <Brian Cameron Sun COM>
- To: Jeff Cai <Jeff Cai Sun COM>
- Cc: screensaver-list gnome org, Alan Coopersmith <Alan Coopersmith Sun COM>, gdm-list gnome org, GNOME Accessibility <gnome-accessibility-list gnome org>
- Subject: Re: Screensaver Solution Discussion
- Date: Mon, 08 Feb 2010 19:00:37 -0600
Jeff:
Some comments:
Hi, I updated the screensaver working process to reflect what I got
recently. Here I didn't detail the pam to make things simplified.
1. After the user A logs in, a gdm's gnome-screensaver (gdm user
session)
process will start. This gnome-screensaver will share the same DISPLAY with
A's gnome-session.
Note: For every user's session, there will be a gnome-screensaver process running for it.
2. When A's gnome-session tells the session is idle, gnome-screensaver
will start a full-screen window, lock the whole DISPLAY.
Note: gnome-screensaver of the 'gdm' user needs to know the DBUS address of
user A's gnome-session. Since user A's gnome-session is created by gdm (currently it is
gdm-session-worker), we can find a way to get the DBUS address. And user A's DBus
session should be allowed to communicate with the gdm process.
3. If a user hits the keys or move the mouse, an unlock dialog will pop up on the
same display.
Note: Here we can use the same GUI as that of gdm-simple-greeter, and the same PAM
backend as that of gdm-session-worker. But we need to set the user name before calling
pam_authenticate for gdm-session-worker.
gnome-session-worker:
Currently gdm-session-worker supports several working states:
SETUP_COMPLETE->AUTHENTICATED->AUTHORIZED->ACCREDITED->SESSION_OPENED->SESSION_STARTED
For gnome-screensaver, we need to add some new states in the state diagram:
SCREENSAVER_SETUP_COMPLETE->SCREENSAVER_AUTHENTICATED->SCREENSAVER_AUTHORIZED.
Is it really necessary to define new states? Since GDM uses GObject
object-oriented techniques, I would think that it might make more sense
to manage this via making two subclasses of a base class. The
lockscreen subclass could just have no-ops for the states that are not
meaningful in the lockscreen case.
gdm-simple-greeter:
3a) If VT with GUI support is enabled, gnome-screensaver will ask gdm-simple-greeter to show
the unlock dialog and login panel on another DISPLAY, and ask VT manager to switch to that
DISPLAY.
Note that there may be other configurations that might support
switching. GDM should not care if the display supports VT or not. GDM
should only care whether the display supports switching. The details
about how switching is managed should be private to the ConsoleKit code.
gnome-session of GDM keeps running with a different DISPLAY as the user A's gnome-session. This
DISPLAY is reserved for the system, and the user can not switch to it manually.
Does VT support restricting a VT in this manner? Again, it should
really be ConsoleKit that manages how VT is used. GDM and gnome-session
shouldn't have to be aware of anything VT-specific.
Then the user inputs the correct password, GDM tells gnome-screensaver to destroy the window
and release the keyboard and the mouse. Do the VT switching to the user's DISPLAY.
3b) If VT is not enabled, gnome-screensaver will ask gdm-simple-greeter to show the unlock
dialog and login panel on the same DISPLAY.
Again, I'd say if display switching is not available.
For the support of a11y,
1) GDM will just launch the gdm-simple-greeter, and not run a new gnome-session. Some relative
processes should also be started: gnome-setting-daemon, at-spi-registrd, dbus-daemon.
2) If the gnome-session of gdm can be coexisted with the A's gnome-session, things become simple.
I'll investigate more about whether two gnome-sessions can share the same DISPLAY or not.
Yes, this will require some investigation. If the above options do not
work well, then it may be necessary to develop a new dialog to be used
in this case. But it seems that a nicer solution would be to reuse the
existing code if possible.
Then the user inputs the correct password, GDM tells gnome-screensaver to destroy the window
and release the keyboard and the mouse.
Overall, sounds good. It sounds like the next step would be to try and
prototype something to get a better feeling for how well these ideas
work in practice.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]