On Tue, Jun 14, 2011 at 11:05 PM, Harald Sitter <sit...@kde.org> wrote: > On Tuesday 14 June 2011 14:55:58 Shaun Reich wrote: >> How does lightDM even handle different authentication types? KDM has a >> plugin system which handles different auth types (fingerprint, >> winbindd, etc.). >> >> However, the fundamental flaw that I can see..is that at some level or >> another, the UI/Greeter *has* to know what type of authentication type >> it is. That is why KDM has plugins which wrap around PAM(sort of), so >> that the interface can properly accommodate for the changes in auth >> type. Note these plugins apply to the screensaver unlock dialog as >> well. >> >> I've been toying with the idea in my head, of using the same Plasma >> plugin (actually an applet + dataengine which wraps around a main, >> more generic dataengine) in tandem with the Plasma integration with >> the screensaver, that is currently present. I think it'd be quite >> trivial for me to do this, too -- since I specifically tried to not >> make assumptions. >> >> The plugins exist (both in the plasma frontend and regular kfrontend) >> so that when it's in fingerprint mode..it won't show a textbox or any >> useless stuff like that, and may additionally show a diagram of some >> bloke wiping their finger across. (that's what the kdm plugin does >> actually). >> >> Anyone familiar with the structure in lightDM care to enlighten? > > I am not sure it does right now.
LightDM also wraps PAM and then sends the requested type to the greeter. It wraps each service and presents them as one of two methods. showPrompt (display a message and requiring text input) and showMessage(display a message to the user) such as "swipe a finger". This means if you have swipe access login you'll be told to swipe, same for all the 2 factor authentication types requiring additional pin numbers. It is a bit crap at present, but it does work for the vast vast majority of use-cases. Right now the API is not fixed, but I don't think this will change for their first release. I hope we can have a BOF at the desktop to sort this out. It is the one area of LightDM that I think needs some work. I wasn't on KDE-Core-Devel (only KDE Devel), so I've been trying to catch up on the thread from the mailing list thread. So to settle a few things I've read: Bzr vs Git: Only QLightDm (the library between the daemon and Qt greeters) is in the bzr. My currently written KDeclarative greeter engine, and KCM are all in KDE's git in my scratch area. Anything actually KDE related can and should be in our own repos. "We don't have control over it" / "People making us switch": Canonical aren't forcing anyone to switch, in fact it started as an independent project. I approached Robert (the LightDM guy) because LightDM looked cool and to see if I can make something better for my desktop, and for KDE. Robert's been great, and is as open to suggestions as much as anyone working in KDE. Getting involved early in Freedesktop work is by far the best way to shape where we want it to go. Only the backend daemon and client lib are in a different repository (which is still perfectly under our "control"). All the interface stuff is public. Power Management: We have an interface to uPower in the greeter library. It seems to work fine. A KDE Greeter /could/ do something different if it wanted to, but I'm not sure what it would gain. Honest opinion: Right now, it's not as good as KDM. I get all the LightDM bug reports, and they're coming quick and fast. However, it's got a _lot_ of potential. We get a lot work shared - and idea of plugin-able backends for LightDM has we get a lot of cool stuff and future proofing. Wayland support is already on the cards, Plymouth integrates and works. All the little bugs will be fixed before too long, and it will match KDM in stability/features within a few months. Does KDM still run the greeters as root? David Edmundson > > David Edmunson should know. > > -- > Harald >
