speechd-up

[William Hubbs]

Hello Hynek and all,

As a developer who has worked on the speakup project, I am going to try
to answer this as well as I can, but I'm sure I'll be leaving something
out.

On Fri, Jul 30, 2010 at 12:54:36PM +0200, Hynek Hanke wrote:
> On 29.7.2010 23:32, William Hubbs wrote:
> > Does Brailcom have any plans to restart maintenance of speechd-up?  If
> > not, I am willing to volunteer to maintain it.
> 
> First of all, thanks for the proposal!
> 
> We don't want to continue the current way of Speakup and
> speechd-up because it is harder and harder to maintain
> in the current state. We are however open for further
> development of both technologies that will take it to a state
> where it gets up to the current standards and get us a chance
> to maintain interoperability.
> 
> The two major reasons why the current state is unsufficient
> are as follows:
> 
> 1) Although we likely need some improvements
> in the kernel for text console accessibility, it
> is inapropriate to have the whole screen reader
> in the kernel. This is also a reason why it was
> never accepted to the official kernels and why
> most distributions do not even offer Speakup
> kernel packages and some of those who did in the
> past have dropped it.
 
 Whether or not it is appropriate to have a screen reader in the kernel
, as far as I know, is an opinion, and I don't think it had anything to
do with why speakup wasn't accepted into the kernel.

I can personally say that I know of one technical issue which is
preventing it right now.  That is the way it communicates with serial
ports, which is not standard.  I do not know of other issues, because it
was submitted to the kernel devs for review years before I got involved
with the project.

The reason it was dropped by some distributions in the past was that, in
the early days, using speakup actually involved patching the kernel and
it could not be built outside the kernel tree.  Since linux 2.6.26,
however, it is possible to build speakup as a series of external kernel
modules.  As a result, I believe it is offered as a package on Debian
and Ubuntu.  I know it is offered on Gentoo, because I package it for
them.

> Movement of the actual screen reader
> application into user space would finally allow
> to integrate it with software speech synthesis
> much better, do proper internationalization,
> operate USB screen readers and such.
 
 I can't speak much to this, but I can say that speakup does now have a
 way to allow you to translate its messages to other languages, but I
 don't know how well it works, or what character encoding it supports.

 The USB ssynthesizer issue is an issue for us whether or not the screen
 reader is in user space.  I have a project personally that I have been
 working on which will be some kernel level drivers for the dectalk usb
 and tripple talk usb.  They aren't ready to be tested yet because they
 do not support indexing.

> I'm sure clean improvements would
> be accepted into the official kernels, which
> would be a huge improvement for the users.
 
 I, personally, would like to see this happen.

> 2) speechd-up runs as a system service which
> is wrong for this type of application. speechd-up
> needs to move into user session. This will involve
> integration with ConsoleKit and extending ConsoleKit
> with the "idle" user session, as was already discussed
> for Speech Dispatcher.
 
 The only reason speechd-up runs as a system service is the permissions
 on /dev/softsynth.  I think I could set up a udev rule that would
 change the group on the device, to say, speech, or audio, or something
 similar.  Then I could set up speechd-up to run as a user in that
 group.

 I don't know anything about consolekit, but would that arrangement fix
 this issue?

William

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://lists.freebsoft.org/pipermail/speechd/attachments/20100730/bd51b75a/attachment.pgp>