KDM plans and lightDM

[David Edmundson]

On Tue, Jun 14, 2011 at 11:05 PM, Harald Sitter <sitter at 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
>