[BRLTTY] Activation of Speech Dispatcher under squeeze

[Samuel Thibault]

Cc-ing brltty as it really matters there.

Hynek Hanke, le Thu 23 Sep 2010 14:39:42 +0200, a écrit :
> If you are using ALSA and have a multi
> channel soundcard or DMIX set up, it will speak.

DMIX is set up by default nowadays.

> However, Pulse Audio will refuse to play sounds originating from
> the root user to ordinary users. And I think for very good
> reasons.

This seems reverted logic to me actually.  Root can output text to
ordinary users at will, nothing bars him from doing that either on the
linux console, or X11, etc.  Why should audio be different?  If an
administrator erroneously says a password loud in the user's speakers
that's the dumb administrator's concern (he can as well just write them
in world-readable files), and it shouldn't bar normal administrators
from doing proper outputs as they consider appropriate.

The contrary is however true: a normal user shouldn't be able to output
sound if he's not in front of the machine.  Only root should be able to.

> I think BrlTTY needs to have a better notion of users and sessions
> and then it will interconnect well with Pulse Audio, DBUS and the
> other desktop technologies.

How do you log in?  Which user is supposed to provide the audio
feedback?

> Speech Dispatcher is just an intermediate who can't do much about it.

Well, the issue is that we're here mixing unix users with physical
users. What we really want is to identify the real user, while
pulseaudio/dbus/brltty can only deal with unix users. And another issue
of course is that to actually be able to read the linux console you
need to be root. Or open the vcsa device first and then change uid. But
then when logging out the kernel would need to revoke access to the
already-opened vcsa device. This is becoming really hairy, we really
need to have a good reason to do it that way.

> >If the user later starts an X session then we don't want a second
> >speech-dispatcher instance to be started, as this could then compete for 
> >the
> >audio device with the global instance - exactly what Speech-Dispatcher is
> >designed to prevent.
> 
> To prevent concurent speech, in the users session model, Speech
> Dispatcher will use ConsoleKit in the 0.8 release. This is not to
> say that only one will be active at a time. As many will be active
> as many active sessions there are (same computer, multiple seats etc.)

Does consolekit handle sound cards associated with keyboard/mouse/screen
sets?

> >3. Gdm log-in, possibly in combination with any of the above scenarios.
> >Likewise for other X-based log-in tools that might become accessible at 
> >some
> >point.
> >   
> 
> GDM runs in its own session, so there is no problem. Speech Dispatcher
> gets started, when GDM tries to use it.

What about console screen login?  We'll have to patch
login/agetty/mgetty/*tty, as well as kdm/xdm/...?  It's really painful
that it has become an _obligation_ in nowaday's pulseaudio mind.

> Work is also needed in BrlTTY and Speakup.

Report is needed to actually get anything done.  AFAIK, neither BrlTTY
nor speakup people were involved in any pulseaudio discussion about all
this.

Samuel