Re: [gdm-list] how to use authentication feature of GDM in a screen saver

[Oswald Buddenhagen <ossi kde org>]

hi,

On Fri, Apr 09, 2010 at 11:43:27AM -0400, Ray Strode wrote:
> I agree it would be good to have better infrastructure than what we
> have for screen lockers in XFixes or whatever, but I'm not exactly
> sure what that better infrastructure would be.  Maybe it could just be
> two things:
> 
> 1) A new kind of grab that supersedes pointer and keyboard grabs
> (XGrabInputDevices ?), without taking other clients out of the
> server's select() loop like XGrabServer
> 
> 2) an api that lets one client atomically transfer grab ownership to
> another client
> 
what one really wants is effectively requesting a new x server within
the existing server. everything would be separated (window stacking,
input masks, grabs, properties), with the nested server taking control
over the physical console. i wonder whether the server should actually
open a second display port, but i think just a separate xauth on the
same port should be sufficient (and less problematic when it comes to
firewalls/tunnelling).
the problem about trying to add more general solutions which aim at
particular aspects is that there will be always something new you have
to deal with in some more or less sophisticated way. by having this
context separation extension, this burden would be shifted to the x
server, once and for all.

> >> > but i wonder whether one should get straight into that mode or
> >> > whether it should be reached via a separate menu point from a
> >> > more classical "user bound" screen lock.
> >>
> >> If the factory is already running, doing the switch immediately
> >> probably makes sense, since it should be quite fast.
> >>
> > i wasn't wondering so much about speed (yet). it's a general user
> > interaction question.
>
> If speed isn't an issue, it's clearly better to not have a dialog that
> asks if you want to go to the real dialog.
> 
well, that dialog would be the normal unlock dialog. the question is
whether one wants to completely merge unlocking and user switching or
whether switching is considered sufficiently less common than "just
unlocking" that it should be "hidden" behind a separate button.