KDM plans and lightDM

[Harald Sitter]

On Tue, Jun 14, 2011 at 12:02 AM, Alex Fiestas <afiestas at kde.org> wrote:
> On Monday, June 13, 2011 10:24:22 PM Thomas Lübking wrote:
>> Am Mon, 13 Jun 2011 21:34:56 +0200
>>
>> schrieb Martin Gräßlin <mgraesslin at kde.org>:
>> > What does power management has to do with KDM? This belongs into
>> > powerdevil where to my knowledge it should be handled fine, if
>> > configured correctly.
>>
>> I guess he means:
>>    "autosuspension from KDM", ie. w/o being logged in at all - he
>>    started the system, didn't log in, talked a lot of meeting nonsense
>>    (tm), legged in - and the battery was sucked away.
>>
>>    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.
> I don't really know what a DM should and should not do, so yes, a cron job
> should do the work just fine.

How would one do this using a cron job? :O

>> 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.
> I'm not sure what's needed to integrate a DM with plymouth (the splashy
> replacement), though I know that KDM without patches doesn't have a smooth
> transition. There is a patch from the Fedora team that won't be applied into
> KDM because it is crappy (ossi says).

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

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 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...
> The 95% of desktop users doesn't use either sshd or a webserver. So at least
> this should be configurable.
>
> GDM loads the "gnome power management" to solve the issue, what KDM does?
> can KDM maybe launch kded with some daemons?

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
"do-not-break-me-server".

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.

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

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.

regards,
Harald