KDM plans and lightDM

Hi there

Today something happened to me again, I turn on my laptop at the begining of a
meeting and when I needed it the battery was over because the laptop didn't
went to suspension (as I'm used).

That makes me wonder what are the plans for KDM in this and other regards
since I haven't seen much activity on it (apart from bugfixing).

Also, since the last Ubuntu Development Summit I started to look into
lightDM[1] as a possible alternative (at least for my use), I event managed to
patch kdisplaymanager.cpp to play nice with it.

I'm not an expert on Display Managers so I can't really tell if lightDM is
good enough (or will be good enough) to replace KDM. When I asked to some
distribution people the first thing they told me is: "Does it support XDMCP?"
and I don't know even what XDMCP is...

So, what are the plans for KDM? can we expect some power management
integration? and plymouth?

For the experts: Does lightDM feel nice as a cross-desktop solution? is it
good enough?


[1] <a href="" title=""></a>


Re: KDM plans and lightDM

By Sebastian =?utf... at 06/15/2011 - 05:00

Hi Alex,

On Monday, June 13, 2011 21:10:36 Alex Fiestas wrote:
I don't think it's a solution to the problem. LightDM doesn't have any
integration with powermanagement agents, so it doesn't solve the problem. Goes
a bit like this:

- "Hm, KDM doesn't have power management support"
- "Let's think about LightDM then!"
- "LightDM doesn't have it either"

I think it's nice that someone's working on a replacement, but it seems to be
kind of chicken-headed. What are the problems with KDM right now?

1 bit arcane UI, litlle themes
2 takes long to start
3 no PM integration
4 no touch input support

(Note that the above comes from the top of my head, possibly you can do even
one or more, but the default roughly looks like the above. Correct me if I'm
wrong, please.)

I think lightdm solves (2), but does so by cutting features, features which we
probably need (some asked for XDMCP as an example). So lightDM might be useful
for a specific situation where you need only the feature set that lightDM

On the other hand, KDM is rock-stable, secure and maintained. It's not shiny,
and hasn't been built with "devices" in mind. As a result, I'm quite
skeptical. But let code decide, not assumptions.


Re: KDM plans and lightDM

By Oswald Buddenhagen at 06/15/2011 - 07:23

On Wed, Jun 15, 2011 at 12:00:00PM +0200, Sebastian Kügler wrote:
if you adapt xdm's Xt frontend to the backend's last 10 years of
development in kde, you will still easily get the fastest dm
realistically possible, and demonstrate that kdm is just as
"cross-desktopy" as fooDM could ever claim to be.
i originally wanted to push my stuff back to X, but the frontend/backend
interface is just too unstable to actually have independent projects.
i.e., the backend and frontends need to be all in one repo (that may be
realistic now, but was a pipe dream at the time i was really active).

and fwiw, gdm 2.4+ is also a contender for The Cross Desktop DM. the
backend doesn't need anything else than glib (incl. gobject and d-bus
bindings), which is about as much as lightDM needs. kdm beats that ...

Re: KDM plans and lightDM

By Tom Gundersen at 06/13/2011 - 14:50

Hi Alex,

On Mon, Jun 13, 2011 at 9:10 PM, Alex Fiestas < ... at kde dot org> wrote:
I cannot speak to the suitability of lightDM as a KDM replacement.
However, I just wanted to point to a couple of discussions about this
from gnome-land (as one of the aims was to be cross-desktop)[1,2].

As to power management: I never quite understood why the power
management policy daemons are implemented inside the DE's. Shouldn't
this be a system-wide daemon, that could be controlled from the DE's
(similarly to what Network Manager is for networking)? This would give
reasonable power management also when logged in from the console, or
as your example illustrates, not logged in at all (at the console or
in the DM).



[1] <a href="" title=""></a>
[2] <a href="" title=""></a>

Re: KDM plans and lightDM

By Alexander Neundorf at 06/14/2011 - 10:44

On Monday 13 June 2011, Tom Gundersen wrote:
I think so too.
This should be a system-wide setting, since it very much influences a system-
wide thing.
E.g. I don't know what happens if two users are logged in to one laptop (this
happens in reality), and they have different power management settings.

Somehow (at least with SUSE 11.2...11.4) my laptop also never suspends on
closing the lid while the screensaver is active, it only suspends on closing
the lid if the screensaver is not active. Is this maybe for a similar reason ?


Re: KDM plans and lightDM

By Martin =?ISO-88... at 06/13/2011 - 14:34

On Monday 13 June 2011 21:10:36 Alex Fiestas wrote:
Btw. I consider it as a very good thing that KDM does not require any more changes than
bugfixing. I think it is extremly important to have a rock solid DM.
We will also have to do some work to bring Wayland support to KDM. I do not have an idea on
how to do it, but it's one of the big issues (btw also for lightDM).
I have no idea what lightDM provides and what not, but I am very sceptical about changing
this important part of our workspace offerings. We are just at the edge to transit to another
windowing system which will require changes in the DM area, so if lightDM supports
Wayland it makes sense to consider it as an option. If it does not, we should better stick to
what we have for X11 in order to not change the DM twice in a short time. We also have to
keep in mind that even when we transit to Wayland as our default we will also have to offer
an X11 solution. For me it is clear that users should not notice a difference whether they use
X11 or Wayland - also in the login manager.

Kind Regards

Re: KDM plans and lightDM

By Tom Gundersen at 06/13/2011 - 14:57

On Mon, Jun 13, 2011 at 9:34 PM, Martin Gräßlin < ... at kde dot org> wrote:
Just my two cents:

I think the idea is that while currently Plymouth is before KDM and
power managment is after, it would be nicer if this is not the case.

I.e., integrate Plymouth with the DM's so it transitions nicely with
no flicker on start-up (this I think is the case already in GDM), and
integrate the power managment daemons with the DM's, so they can be
started before the user logs in (this is also already the case in


Re: KDM plans and lightDM

By =?utf-8?Q?Thoma... at 06/13/2011 - 15:24

Am Mon, 13 Jun 2011 21:34:56 +0200
schrieb Martin Gräßlin < ... at kde dot org>:

I won't comment on the preferred usage of advanced bioneural cpu to
circumvent such issues in the first place, but this function does imho
not belong into a DM but into some cron job (or whatever other daemon)
that watches how long nobody has been logged in and *whether no relevant
daemon is running* and then suspend the system after some time.
This should also cover plymouth (the splashy replacement? really?) -
but if you mean "bash", you'll require the feature (watching
keystrokes) there, i think.

Putting this into a DM is rather bad because there's no good default*
and it's not a DM's job to watch other processes (while maybe other
logins...) and manage some random blacklist on them.

*you do not want to suspend your system because you didn't log in since
(despite starting to runlevel 5...) there's currently some sshd up and
you're logged into from somewhere else, or just because the machine runs
a webserver as well...

<a href="" title=""></a>

Errr... hopefully *a* - and not *the* kdm frontend.

If it's just about the look:
move the plasma frame rendering stuff to kdeui. done.
I'd write you a plasmatic general UI style to prevent this ;-)

But allowing "random" scripts in a login manager is like asking
people to shoot themself.
Sorry for being rough now, but that is really a braindead idea and
at best acceptable for the single user desktop (ie. the ppl. who
probably use autologin anyway), but certainly *not* in a hostile
Really not.
The purpose of the login manager is to allow reliable and secure
login. That's it. If it's cute on top: nice.
But plasmoids are really the opposite of "secure" - you'd have to tell
everybody to carefully inspect the plasmoids tehy want to put into the
DM, or provide a database of trustworthy ones and who's gonna do that?


Re: KDM plans and lightDM

By Alex Fiestas at 06/13/2011 - 17:02

On Monday, June 13, 2011 10:24:22 PM Thomas Lübking wrote:
GDM loads the "gnome power management" to solve the issue, what KDM does?
can KDM maybe launch kded with some daemons?

It may no be perfect but lightDM at least does some handling directly talking
to UPower, though I agree that DM is not the place to fix this issue.

Re: KDM plans and lightDM

By Harald Sitter at 06/14/2011 - 03:55

On Tue, Jun 14, 2011 at 12:02 AM, Alex Fiestas < ... at kde dot org> wrote:
How would one do this using a cron job? :O

IIRC the transition is straight forward. Essentially KDM just takes
over the VT from plymouth and quits latter once the X server is up and

Considering the Fedora patch is inferior, it makes me wonder why there
was no superior solution created by those that know better. Are
distributions not important enough stake holders of KDM?

You'd still need to provide configuration for this, as the point about
running servers still holds. IIf you are running a server of whatever
kind on your machine and stay at DM while using it, you do not want to
have the machine suspend for lack of interaction, so the simplest
solution would be to provide an option in the DM KCM

As for the logged in on tty cas: If I am not mistaken that is exactly
what ConsoleKit is supposed to solve. Every login shell you run should
AFAIK result in a seat on ConsoleKit. So, except for the server use
case that should cover the greater part of false suspension scenarios.

Agreed. As Tom pointed out, ideally we'd have a desktop independent
daemon to take control over power management. By desktop independent I
really mean "eventually cross-desktop" (as in: used in >1 desktop
env). This would also allow applications to inhibit suspension (think
video player) on every desktop that supports the daemon.
Though, this is likely not going to happen any time soon, perhaps even
never, so a sensible solution ought to be found. Even if not the most
elegant, power management in the DM (or invoked by the DM, i.e. kded
with powerdevil) seems like a good enough approach to solve the issue
for the majority of desktops users.


Re: KDM plans and lightDM

By =?utf-8?Q?Thoma... at 06/13/2011 - 17:16

Am Tue, 14 Jun 2011 00:02:02 +0200
schrieb Alex Fiestas < ... at kde dot org>:


Re: KDM plans and lightDM

By Shaun Reich at 06/13/2011 - 15:46

On Mon, Jun 13, 2011 at 4:24 PM, Thomas Lübking
<thomas. ... at gmail dot com> wrote:
Of course *a*. I even went out of my way to specify it in other blog
entries, multiple times iirc.

I guess I should implement a big blinking marquee for the impaired as
well as for the ones who can't read.

It isn't just about the look. But you have fun with implementing that.
I'd love to know how flexible and clean the code is </sarcasm>

See "plasmoids" bit, further below...

A "hostile" environment? If they have access to your PC you're screwed
anyways. Anything less than hostile is what any login manager would be
providing for. Nothing more. If you're trying to prevent total access
to your computer from non-average users, then you're fucked regardless
of what method you use.

Duh. You've got to be joking. Okay, how about you read up on the my blog, before criticizing what you clearly
are clueless about?

The sysadmin would easily be able to prevent any additional plasmoids
from being added. That's built into Plasma's kiosk abilities.

Oh but you knew that before responding, because you know all about
this subject, or have at least half-ass read up on it. I see.

Not only that, the applets only run as user. So if the sysadmin did
not disable that, and the user can add them...tell me..what are they
going to do?

Blink excessively? You're right, I'll get right on that.

Re: KDM plans and lightDM

By =?utf-8?Q?Thoma... at 06/13/2011 - 17:03

Am Mon, 13 Jun 2011 16:46:12 -0400
schrieb Shaun Reich < ... at gmail dot com>:

OFF TOPIC ----------------
<a href="" title=""></a>
"using the same theming system"
"Line edits, button mouseover, click events and more, will all look
nice and at home with the rest of the system"
"Wallpapers will be fun also."
"From a clock, battery monitor, the kdm greeter (of course. you know,
the login dialog), system monitors, disc usage, sticky notes,
calculator, on-screen keyboard"

You got a better link why else using plasma is great?
Oh, and did you see "on-screen keyboard"?

which usually fails (used to?, actually not tried lately) if you deviate
from oxygen's margins & paddings because it (implicitly) uses (used? no
idea whether this has ever been fixed) the style to calculate the size
but the theme paddings to render clipped strings?
/OFF TOPIC ----------------

Especially the KDM frontend is not the best location for permission
leverage attempts.

I however don't worry about professionally administrated systems at all
(because such things rather won't show up there, by no means) but the
small-to-mid (or just badly) semi administrated stuff (which is
apparently the core audience for this as well) - maybe run a query on
kde-apps on who uses or even knows about kiosk.

Overlay the input fields?
Scam logins & passwords?
Maybe just hook on textChanged signals for that purpose?

I haven't read the code, so i frankly don't know what kind of security
levels you've added to prevent such, but it is dangerous (as
mentioned: not in the meaning of leverage, but information gathering)

And really, since the DM greeter is a 3 second "see, type, enter" thing,
I wonder why anybody should add any kind of risk level for some stupid
custom clock there.

Maybe i'm just too old now, but i do really not see the
least reason for that at all.


Re: KDM plans and lightDM

By Shaun Reich at 06/13/2011 - 18:38

On Mon, Jun 13, 2011 at 6:03 PM, Thomas Lübking
<thomas. ... at gmail dot com> wrote:
No problem. Just don't try to critique something until at least
reading up on it (which someone else linked to previously in the
thread, even).

Again..huh? I really don't know what you're trying to get at with
this. The point is we get all of that for free. Whereas if you do not
use the whole of Plasma, you have to do it all yourself (take a look
at kdm's kfrontend code which creates a clock and such. Just makes
things easier when there's zero duplication.

Sorry, can't comment on this as I've no idea what you're referring to.

The same can be done using kdm's authentication plugins. I could go
and make my own right now to do just that, and if the user has root
access and installs it, that's the (stupid) user's prerogative. Just
like installing any other application on a desktop could do the *very*

This is of course, coming from the perspective that the user is a system admin.

You are aware that in order to add applets to the greeter (if that
option is enabled, per system admin), you need to authenticate as root
(which is presumably what the system admin only would have).

So please don't think this is "anyone who walks by can go and monkey
around with it". It sounds like that's what you're confusing it as.

Once again, you're backwards. YOU NEED ROOT ACCESS TO ADD APPLETS. I
just want to emphasize that. The "the sysadmin can disable that" was
referring to a button, a la what the cashew has, to unlock widgets and
be able to add them. To do that..once again, *requires root access*. I
was simply referring to visually disabling it. It still wouldn't be
functional without root access either way, out of the box.

Sorry, but I don't think you read my blog entries thoroughly enough.
Just as using a utility without reading the man page can destroy your
system, so can replying to a mailing list without having at least read
up on existing docs ;-p

See above. The same *exact* thing could be done if someone just
installed a custom PAM authentication. Seriously. What do you expect
if the user has root access, is able to install anything he wants, and
installs a malicious piece of software? Are you entirely unaware of
how malware works? Malware plays upon the users stupidity with
elevated privileges. If you never elevate the privileges, what's going
to happen? Well. The software wouldn't be installed, for one.

I really think you are thinking incorrectly. This situation can be
applied to ANYTHING. Give full access to someone and they had better
know what they are doing, because if they are stupid enough to install
compromising software on their system -- then their system just got
compromised. That's the fundamental flaw in any security model: the
user who has root access.

(think that covers everything in this thread..onto the next, hehe)

Re: KDM plans and lightDM

By John Layt at 06/13/2011 - 15:01

On Monday 13 Jun 2011 20:34:56 Martin Gräßlin wrote:
Not sure, but I wonder if Alex means he wasn't logged in so powerdevil
couldn't work?

It seems quite fashionable to start a project on without
involving KDE and to build it using Gnome tech, then ask us to use it because
"it's a cross-desktop project". How are they supposed to know what our
requirements are without asking us? What are the criteria for getting fd.o
hosting/blessing these days?

Note I don't know if this is the case for this project, I haven't heard
anything about it before, but I may not be on the right lists. Enlightenment
gratefully received.

</Grumpy Old Man>

Re: KDM plans and lightDM

By Alex Fiestas at 06/13/2011 - 16:44

On Monday, June 13, 2011 09:01:06 PM John Layt wrote:

Re: KDM plans and lightDM

By Shaun Reich at 06/13/2011 - 15:29

Oh yes. Apparently it's better than KDM because it's very
cross-desktopy. And better. And stuff.

Whatever the hell that means.

And it doesn't depend on any toolkit except glib!!

Which, KDM has had since the beginning with it's separation between
backend and frontends.

lightDM is also headed by my dear friend Canonical, as is clearly seen.

Of note is that ldm uses d-bus, whereas kdm uses sockets. So as for
the "lightweight" part, they just forced everyone to have a full dbus
session up.

Instead of working with existing code, *apparently* it is more
effective to make a new project altogether. I think we should adopt
this strategy. After all, isn't KDELibs and KIO getting really old and
crappy? Time to rm -Rf / and start from scratch...

Oh wait. The *same exact* situation was presented to us with GIO.
"create something new, disregard existing implementations, force
adoption after everything is finalized." Well, so I guess that base is
already covered..lets find another one.

Evidently age is indicative not of stability or refinement, but of a
dying animal, ready to be put down. mjg95's blog entry hits the nail
on the head.

I also laugh out loud at how the project brags about having "much,
much less code than $kdm/gdm". But what do you think the code was
there for? Did we have 50,000 lines of code accidentally copied
somewhere? I think not. I'm pretty sure it's self-evident that the
code actually *serves* a purpose. Purposes that LightDM still has
marked as "well...we don't *quite* have that juuusssttt yet". But hey,
my powers of observation must be astounding.

</rant rant rant>

Re: KDM plans and lightDM

By Martin =?ISO-88... at 06/14/2011 - 01:16

On Mon, 13 Jun 2011 16:29:45 -0400, Shaun Reich < ... at gmail dot com>
There are of course more issues to think about when considering using
something in our workspace that's developed by Canonical. What about we
need changes Canonical does not like for what reason ever? Who of us can
work with launchpad and bazaar? It's not the environment we are used to
work with (same true for GNOME devs who want to participate in
development). Personal opinion: if Canonical wants other to use it as
real cross-desktop, the first step should be move the code into
freedesktop's git repository.

Re: KDM plans and lightDM

By Harald Sitter at 06/14/2011 - 03:35

On Tue, Jun 14, 2011 at 8:16 AM, Martin Gräßlin < ... at kde dot org> wrote:
<apachelogger> robert_ancell: ahoy, is LightDM covered by the
canonical contributor agreement?
<robert_ancell> apachelogger, no
<apachelogger> robert_ancell: ever going to be?
<robert_ancell> apachelogger, no
<robert_ancell> apachelogger, the greeter we develop will be afaik,
but the rest of it not

Indeed, issues worth considering.

I personally believe that "wanting to have something the other party
does not" is really a global issue to all of free software. If I want
Amarok to be able to remote control my space ship, but the Amarok
developers do not, then there is little I can do about that as a
non-contributor. Well, except for trying to convince them from the
long-term advantage that such a feature would provide. If however I
would want Phonon to have such a feature, it is more likely to get
accepted as I am contributor to Phonon. I suppose it is a bit of a two
class society for every project those-that-do-stuff vs.
those-that-don't. While we should keep this in mind, I do not
generally think that it is something to base decisions on. From the
preemptive fear of not having 100% of control we'd otherwise have to
clone every library we use. Well, actually even the OS. Hello KDEOS ;)

I agree with your argument that code should be hosted in a FDO git
repo, though I personally believe that Launchpad is from a management
perspective much easier to use for small projects as it puts every
aspect of management into the hands of the project itself (commit
access to repos, bug management etc. etc.). So, I can completely
understand why one would be using LP even as a
project/thing, even if I find it not sensible at all to do this while
using the website, thus fragmenting one's project
But generally speaking I also see this is as a non-issue in terms of
the discussion at hand. The hosting system in particular is an
implementation detail of forming grounds to collaborate on. Now, to
ask anyone to use a ground we are familiar with (vs. one the other
party is), we'd first have to know that we want to collaborate. At any
rate it probably does not make sense to take such things into account
for any technical discussion as long as the system in use is easily
accessible. Otherwise all of free software would be using Git, not
because it is superior, but simply because everyone else does.


Re: Re: KDM plans and lightDM

By Martin =?ISO-88... at 06/14/2011 - 10:42

On Tuesday 14 June 2011 10:35:49 Harald Sitter wrote:
To my knowledge this would also be a novelty that we replace a part of our workspace with
a 3rd party application.

As a workspace developer I consider the possibility to align all our workspace applications to
our needs as very important. Let's just consider we would want to start into an activity from
the DM... My arguments might seem far*fetched, but from an integrated workspace
development point of view, they aren't (at least IMHO).

Re: KDM plans and lightDM

By Harald Sitter at 06/14/2011 - 13:26

On Tuesday 14 June 2011 17:42:55 Martin Gräßlin wrote:
Hm. Yeah. You are right.


Yet despite having complete control we did not manage to come up with a truly
good workspace experience that starts at the DM (power management, good looks,
I for one have yet to see a sane UI-wise integration of stuff like fingerprint
auth, integration with the workspace like say MS Windows displaying unread
mails etc.).
So, yes, giving away control is certainly a dangerous thing, and needs to be
well throught through and evaluated (if it should happen at all that is). Not
just in terms of control but also in terms of feature parity. It certainly
would hurt the image of the KDE workspace to switch from a capable, proven,
well tested and mature DM to one that does not even measure in terms of
features. Let alone reliability.
With that in mind it certainly would be a good idea if everyone who threw up
rants and whatnot to actually take a look at the status quo and see if lightdm
is a viable alternative for antyhing, and if not how to make KDM provide the
experience that we need to keep up with our competition.

Perhaps we should actually first find out what we need?

Regarding the control issue with regards to workspace integration though...
Maybe I misunderstood the architecture of LightDM, but to me it seems that
all workspace affecting parts would be in the greeter rather than the base of
the DM (I figure that is what we have right now in KDM too). What would be
"outsourced", if you will, is the actual logic of the DM, which for the better
part has little to do with the workspace experience. We would still be in
control of all the UI parts, and the DM logic part is certainly not where most
of the valuable UI plunder should go (that also includes fancyness enabling
technologies such as Plasma). Sure, regarding the actual display management we
would be at the mercy of LightDM and its developers, but from a workspace
point of view I reckon there is not all that much to be done in the DM logic.

I am not the biggest fan of bazaar either, but I think saying it is only used
by one distribution is a bit unfair. Also important projects such as MySQL,
Inkscape, Zeitgeist and various GNU projects such as Emacs and Grub use it. I
would be very surprised if bazaar packages were not available in every serious
distribution. Also unlike git it is not a PITA to use on Windows :P

Anyhow, I do not think this is a topic worth discussing just now.
Seeing as we did not even identify LightDM as anything we need or want to use
in place of own technology. To me the selection of VCS or development
infrastructure at large is at best a political issue.

I'll ask Robert though.


Re: KDM plans and lightDM

By Alexander Neundorf at 06/15/2011 - 11:45

On Tuesday 14 June 2011, Harald Sitter wrote:
Seriously, displaying unread emails ?
From which user ?


Re: KDM plans and lightDM

By Shaun Reich at 06/15/2011 - 11:57

On Wed, Jun 15, 2011 at 12:45 PM, Alexander Neundorf < ... at kde dot org> wrote:
All of them.

MSWIN interates through each user in the listview displaying unread
mails for each. (it's just a count of unread emails..obviously you
don't want other people sifting through some poor bloke's private
e-mails ;)

Re: Re: KDM plans and lightDM

By Martin =?ISO-88... at 06/14/2011 - 15:19

On Tuesday 14 June 2011 20:26:45 Harald Sitter wrote:
Personally I have a completely flicker free boot experience from after GRUB to desktop is
ready to use on my openSUSE systems, so some of the needs are not present for all and
maybe just unknown. And considering how often especially Canonical changed the splash
implementation over the last years, I'm not surprised we don't run behind the latest idea ;-) Oh
and I consider Plymouth as legacy as I'm quite sure somone will have the idea to replace it
with a Wayland Compositor (which would make much more sense).

Re: KDM plans and lightDM

By Harald Sitter at 06/14/2011 - 16:58

On Tuesday 14 June 2011 22:19:40 Martin Gräßlin wrote:
I have not the slightest idea. Perhaps we should start that, to the batcave,
erm wiki!

<a href="" title=""></a>
Search for KDM and be surprised. Considering a downstream applies 16 (!!!)
patches to KDM, something must be wrong (without having looked at them in
detail, supposedly some of them are just distro integration, although those
perhaps also might be accomodated better).

Plymouth is also adopted by Fedora :P
Considering the patch is like 30 lines or so, I do not think that is a valid
excuse though :P

Ack. For getting that adopted by downstream Wayland first needed to come
around. But yes, ultimately Wayland will eat all our graphics.


Should that ever get finished. Shaun?

Well, I can understand Alex' motivation, the issue he experienced is one that
is quite awkard and painful and embarassing.
[putting my Kubuntu hat on] Also, just to make one thing clear at UDS the
consensus was to carry the entire discussion upstream and see if we can get
KDM to become superior awesome. Apparently there is a rumor around that
Kubuntu plans on switching to LightDM. That is not true, we are merely
evaluating the options and what we can do to improve the pre-login experience.

Sure, but there is nothing that prevented us from doing that sorta thing in
the greeter.

I mean, log in via Plasma Active device, if by that you mean I can use my
phone to log me on my PC, probably should be done on a broader scope anyway.
Like "log in through a foobar spec compliant device".

In particular it is my personal believe that a strong separation between DM
logic and desktop binding/integration magic is beneficial from a structural
POV. That way you can easily swap the integration bits (QWidgets -> Plasma QGV
stuff -> Plasma QML stuff?) around without having to poke into the DM stuff at

I do not deny that it has technical merit, but ultimately getting it changed
is political. Either one wants to do it or not. Perhaps there are technical
reasons for the choice of VCS, but more likely just personal motivation like
"seems closest as I work in the Ubuntu environment". Convincing someone (in
this case Robert) to change to a system that is more in favor of our
requirements and preference is however something that can only be resolved (or
not resolved) through discussion, so for the sake of discussion let's for now
assume that LightDM would be willing to move to fdo git if we chose it be part
of our workspace and thus require it be as accessible to the team as possible.

Re: KDM plans and lightDM

By Shaun Reich at 06/14/2011 - 17:37

On Tue, Jun 14, 2011 at 2:58 PM, Harald Sitter < ... at kde dot org> wrote:
Good question ;-)
Yeah, it's in a pretty finished state, after my unintentional hiatus.
Mostly I've been cleaning stuff up(and yes, I've been actively
committing lately), so that the qml code can look the best. It already
runs plasma and qml and logs in, just have a few more things to do on
it. (kinda refactoring a bit so it doesn't come to bite me later on,
at the moment..)

Well, you see. You have to understand my frustration --> the thing is,
this *already* exists in KDM. And anything that is deemed
unsatisfactory(not everything's perfect, naturally) could easily be
changed of course.

Everybody talks about it like it's some magical unicorn that hasn't
been spotted before, but the truth is, it's staring everyone in the

In fact, I have dealt directly with this separation when I've been
working on the Plasma frontend, and based some of it around the
original kfrontend (qwidget) code. So I don't see what the big deal
is, considering I've already worked with this myself...

(also note that the Plasma QGV and Plasma QML stuff are kind of one in
the same, in the case of my code. one can easily make a qgw as the
greeter...of course, I'm using qml. well, unless you're counting
things like the scene and the view. but I haven't found a case for
moving those to qml yet. not that it'd be that difficult, since it's
all modular)

Re: KDM plans and lightDM

By Harald Sitter at 06/14/2011 - 18:14

On Tuesday 14 June 2011 15:37:25 Shaun Reich wrote:

I very much understand your frustation. But also as downstream developer (and
I count Alex in there too as he is very much aware of the advantages of a
downstream POV) I get a lot of input with regards to what is not in the
condition it should be to compete with other pre-login experiences. Be it from
friends or people at fairs, whenever KDM comes up there are some major
annoyances (though to put this into perspective: KDM does not come up as topic
that often, which IMHO is still a bad thing as I'd rather have people go "uhh,
your login thing is so awesome...").

So, to direct attention to the subject. I think the general scheme was to find
out where to go with KDM and whether LightDM would be an option if all else
fails. Find out how to make KDM rock the user's experience is primary
objective, at least for me.

My argument was more in the general direction of moving things that we should
not be heavily involved with elsewhere, and I believe that the larger DM logic
is such an area. By outsourcing (what a nice word) this part in technology
that is used by more than one party we get more exposure to actual production
systems, thus more testing and in the end better quality in the long term (not
that anything was wrong with the quality of KDM, just saying).
Now, I reckon that XDM could, or perhaps should, have been exaclty that,
though it did not quite work out.
It still seems like a nice enough idea to share generally sharable things.

To me, as someone who is not terribly knowledgeable in the area of display
managers, it just seems like a waste of resource to have stuff implemented in
not all that different ways on different ends (GDM and KDM). Though since there
is no plan to have GDM replaced by LightDM on sytems other than Ubuntu this is
all a bit moot. Even though I think sharing with part of the ecosystem is
still better than no sharing at all.

Re: KDM plans and lightDM

By Alex Fiestas at 06/15/2011 - 05:22

Just to clarify something...

I'm not pushing lightDM into KDE in anyway, it is not my favorite DM or
anything like that, though I see it as a highly interesting project with a
healthy and active community and I do think that KDE should be leading the
Qtness of the project as well as be sure that we work well with it.

Also, If KDM developers start to implement all the lacking features such:
-Power Management
-Language switcher
- Maybe more?

And it becomes at least from the outside point of view a healthy project where
incoming patches such the so discussed plymouth one are integrated (I'm not
saying integrate it in the current not optimal state, we've reviewboard to
improve patches) then I will say, go KDM! since KDM is the KDE solution.

But right now: (Once again this is what I see from outside:)
-KDM developers have no plans
-KDM maintainer has no time

And considering that, I think that is not reprehensible if some other
developers are attracted by the idea of a cross-platform DM where in theory we
will need only to take care about the greeter.

So to sum up:
We need to improve the DM experiencie in our Workspace, no matter if it is via
lightDM, KDM or both.


Re: Re: KDM plans and lightDM

By Martin =?ISO-88... at 06/15/2011 - 10:43

On Wednesday 15 June 2011 12:22:10 Alex Fiestas wrote:
So my suggestion: let's stop discussing about lightDM and evaluate what we have and what we
need. Let's do it properly and honestly. Then let's look what can be done in KDM and how we
can shuffle resources there. And only iff that does not work, let's discuss a different DM. And
also let's think about the future. Developing a new DM for X when we are about to switch to
Wayland makes me want to move my palm against my head ;-)

To me this whole issue was unknown until the thread was started and that most likely means
that it has not been raised on the appropriate mailinglists. I don't know if it has been raised
towards Ossi, but if he does not have the time there is always the option to bring the discussion
to the plasma mailing list (where you can mostly find all Workspace interested developers) or on
this list here. Though as it is workspace related, Plasma should be the first choice.


Re: KDM plans and lightDM

By Alex Fiestas at 06/15/2011 - 11:33

On Wednesday, June 15, 2011 05:43:44 PM Martin Gräßlin wrote:

Re: KDM plans and lightDM

By todd rme at 06/15/2011 - 01:20

On Wed, Jun 15, 2011 at 1:14 AM, Harald Sitter < ... at kde dot org> wrote:
There seems to be an implicit assumption here that if we are going to
go the cross-desktop route it would have to be LightDM that we pick.
But if KDM is already pluggable enough that you can easily rip out the
GUI and write and entire new one from scratch, and (as best as I can
tell) already hs most of the features lightDM wants to add, why
shouldn't we basing the cross-desktop DM on KDM instead of LightDM?

I gather from the discussion that most, if not all, the features that
KDM still needs are also lacking in LightDM, while KDM has lots of
features LightDM does not. So if we are talking about wasted
resources, wouldn't it waste far fewer resources to add those new
features and add the Gnome-centric bits in KDM than to add the new
features, old features, gnome-centric bits, and KDE-centric bits in


Re: KDM plans and lightDM

By Shaun Reich at 06/15/2011 - 10:16

On Wed, Jun 15, 2011 at 2:20 AM, todd rme < ... at gmail dot com> wrote: That's precisely what I've been trying to get across this
entire time. But instead of adding anything missing to KDM, it's
instead added to a different, far less developed project.

Re: KDM plans and lightDM

By Alex Fiestas at 06/15/2011 - 05:08

On Wednesday, June 15, 2011 08:20:35 AM todd rme wrote:

Re: KDM plans and lightDM

By todd rme at 06/15/2011 - 10:37

On Wed, Jun 15, 2011 at 12:08 PM, Alex Fiestas < ... at kde dot org> wrote:
There are apparently people willing to implement KDE support in
LightDM, so why don't they instead improve KDM? Why should they be
putting their effort into an immature project instead of a mature one?


Re: KDM plans and lightDM

By Alex Fiestas at 06/15/2011 - 10:46

On Wednesday, June 15, 2011 05:37:14 PM todd rme wrote:
Personally I won't have time to work on LightDM though if I had to work on a
DM I will probably choose LightDM, it is a feel not sure why.

Re: Re: KDM plans and lightDM

By Martin =?ISO-88... at 06/15/2011 - 11:11

On Wednesday 15 June 2011 17:46:08 Alex Fiestas wrote:
which renders lightDM to be used only by Ubuntu and not even by Kubuntu if they stick to their
"we ship what upstream ships".

I think it would be pretty sad if the workspace community would become split due to such

And just as something to remind: there was a time when Lubos seriously thought about dropping
KWin in favor of Compiz, because it was the new cool kid on the block. Look at what we have
today and where Compiz is today (including their history). Would that have been a wise decision
to drop KWin? Not always is cool and new better than old, stable and feature rich.


Re: KDM plans and lightDM

By Nuno Pinheiro at 06/15/2011 - 11:39

A Quarta, 15 de Junho de 2011 17:11:27 Martin Gräßlin você escreveu:

Re: KDM plans and lightDM

By Alex Fiestas at 06/15/2011 - 11:29

On Wednesday, June 15, 2011 06:11:27 PM Martin Gräßlin wrote:
Please, don't close yourself saying "LightDM is rejected by Plasma team"
because plasma has nothing to reject here, if lightDM team does well the work
then would be lovely to have support for it as we support many others NIH

And once again just to be 100% crystal clear, NOBODY is saying let's rm -rf
KDM and put lightDM instead...

Re: KDM plans and lightDM

By todd rme at 06/15/2011 - 10:55

On Wed, Jun 15, 2011 at 5:46 PM, Alex Fiestas < ... at kde dot org> wrote:
So in other words when LightDM is mature no one will work on it and we
will be left with the same problem?


Re: KDM plans and lightDM

By Alex Fiestas at 06/15/2011 - 11:23

On Wednesday, June 15, 2011 05:55:03 PM todd rme wrote:

Re: Re: KDM plans and lightDM

By Shaun Reich at 06/14/2011 - 16:55

Slight shift of topic as well...but:

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 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

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 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

Anyone familiar with the structure in lightDM care to enlighten?

Re: KDM plans and lightDM

By Harald Sitter at 06/14/2011 - 17:05

On Tuesday 14 June 2011 14:55:58 Shaun Reich wrote:
I am not sure it does right now.

David Edmunson should know.

Re: KDM plans and lightDM

By david at 06/14/2011 - 17:59

On Tue, Jun 14, 2011 at 11:05 PM, Harald Sitter < ... at kde dot org> wrote:
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

Re: KDM plans and lightDM

By Shaun Reich at 06/15/2011 - 10:00

On Tue, Jun 14, 2011 at 6:59 PM, David Edmundson
< ... at davidedmundson dot> wrote:
No. It's been not doing that for about a year or so.

Re: KDM plans and lightDM

By Rolf Eike Beer at 06/13/2011 - 14:50

Martin Gräßlin wrote:

<a href="" title=""></a>