Maintaining speechd-up

[Halim Sahin]

Hi,
On Mo, Jul 19, 2010 at 10:06:32 -0700, Bill Cox wrote:
> I only use speech and magnification, so I can't say with authority
> anything about Braille.  However, SBL seems Braille-optimized to me in
> the way it does cut/paste, and the way it doesn't queue speech to be
> read when you issue commands like 'ls'.  Multiple Vinux users have
> stated that they will stick with speakup until at least these two
> issues are resolved, and my straw poll of blind Vinux users is in
> favor of keeping speakup as the default screen reader.  I have
> included SBL in the repositories, so users can install them with
> apt-get, and I've patched the cut/paste command, but I haven't figured
> out yet how to queue speech.

Doing things in kernelspace is afaik the reason for things done in 
speakup.
As hynek said this should be better done in userspace.
queuing the speech is really hard to realize.
Do you know How screenreading works in the console?
Have a look to /dev/vcs and /dev/vcsa.
To implement such feature you must do several things:
1. get a snapshot of the current screen.
2. and poll for changes which you need to
compare with the previous snapshot.
You are not able to go backwards in the vcs devices so you need to
handle this yourself.
This is the reason why no console screenreader reads the changed
information automatically.
This is also the reason why sbl has many commands for screenreview.
BTW.: ls -1 |wc -l in my home gives me
273 files.
so I am not able to think of an useful usecase for reading screenchanges
automaticaly.
If I type ls -1 the pc will read 273 filenames.

> However, I feel SBL can easily be modified to be more speech-centric,
> perhaps with a mode toggle key to switch behavior.  I think SBL is
> fairly well written code, is to read and modify, and I like how it
> integrates in the consoles with uinput, and doesn't do anything in
> kernel space.  I like the application specific keybindings, and the
> simplicity of configuration.  I also like how SBL is separated from
> uinput.  A project I am interested in looking into is somehow gluing
> SBL into gnome-terminal so that we can have the same screen reader in
> both the consoles and gnome-terminal.


Thx, Patches welcome :-).

> 
> Long term I see SBL as the best current platform to build what we
> need, but it can't replace speakup as the default screen reader in
> it's current state.  I would welcome being proven wrong, though!  If
> you could work with the Vinux community to satisfy the concerns of
> current speakup users, we may be able to make the switch.

As time permits I can try to help!

> > @Hynek:
> > Integrating console screenreaders in such session tools is not possible!
> > People who push these technologies are not using screenreaders and don't
> > care about their needs!
> > There are ?many problems to solve when the sr is running as root.
> > It doesn't improove userexperience but makes things more complex.
> 
> Longer term, I believe it is possible to include session integration
> in the consoles in a screen reader compatible way that works with the
> login prompt and works reliably throughout the system.  

I see no advantage of this stuff and don't think this will work more
reliable than the old behaviour.
As written in my previous mail, a sr needs root access for
accessing some devices.

I am not sure if this can be changed without breaking other things.
As said before I was able to run sbl as user but no cursorrouting works
when I do the following:
login to tty1 and tty2
start sbl on tty1
switch to tty2
You have no access for inserting keys. so no cursorrouting possible.

Like the other sessionintegration folks I don't want to start sbl 6
times for 6 tty's and implement a not working suspend functionality when
switching tty's.

We see in opentts/speechd/pulseaudio, that this approach doesn't work
reliable and wastes memory and makes things more complex to handle.

Just my two cents.
Halim