speechd-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Considering ConsoleKit and GSettings/DConf


From: pbrobinson
Subject: Considering ConsoleKit and GSettings/DConf
Date: Wed, 11 Aug 2010 16:30:37 +0100

On Wed, Aug 11, 2010 at 4:14 PM, Hynek Hanke <hanke at brailcom.org> wrote:
>
> Hello all,
>
> I'm posting the reasons why some of us propose
> ConsoleKit and DConf for the 0.8 release. This is
> still open question, so I'll welcome comments.
>
> * Why do we need ConsoleKit
>
> Speech Dispatcher needs to obey the rules for nice
> behavior of user session daemons. Most important:
>
> ? ?1) Free resources when session is not active
> ? ?2) Do not consume CPU when session is not active
>
> Speech Dispatcher is currently not sticking to these rules.
> With Pulse Audio, detaching when in inactive session is not
> so important, but with ALSA and other audio output methods,
> it's crucial since we block everyone else.
>
> Consider the current audio fallback mechanism ,,pulse, alsa''.
> If for any reason (e.g. because early in the bootup process)
> this mechanism starts Dispatcher with ALSA, this breaks
> Pulse Audio output for any user on the system unless they kill
> that Speech Dispatcher. This is completely unnecessary.
>
> (Audio fallback needed to be disabled for 0.7.1 as this is
> a real problem with BrlTTY.)
>
> We also consume CPU unnecessarily. Speech Dispatcher will
> synthesize any incoming text regardless of whether the
> current session is active or not. That synthesis produces sound
> which will never be heard.
>
> This is all also important for running Speech Dispatcher
> in the ``idle session'', as we discussed before, to enable
> reading startup messages, login etc.
>
> Using ConsoleKit, Speech Dispatcher will always know,
> whether it operates in a session which is currently active.
> When the session is inactive, it will detach from resources
> (such as blocking audio) and will not waste CPU time
> for speech synthesis.
>
> I've already tried some testing program communicating
> with Console Kit over DBUS and receiving signals on
> session activity, and I must say it seems easy. We will only
> need to figure out a way how to pass the signal to the modules,
> but that can be done analogous to other asynchronous commands
> which we already use (STOP).

Is that ConsoleKit or rtkit? My understanding on ConsoleKit was for
access to things like physical resources. EG if the user is logged
directly onto the machine itself give them access to the
keyboard/mouse/soundcard/cd drive etc where if they are access the
machine remotely via a remote X session don't give them access to
that. rtkit on the other hand allows access for guaranteeing of
resources and the like.

Peter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]