Maintaining speechd-up

[Trevor Saunders]

HI,

On Mon, Jul 19, 2010 at 08:10:01PM +0200, Halim Sahin wrote:
> 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.

the *point* of speakup is that it is in kernel mode, which has plenty
of issues, but also can be really useful.

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

uh, no. speakup does this by watching the print buffer or something
similar, I've never looked.  yasr can also do this, it opens a pseudo
tty, and watches the input / output to that pty.

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

 come on, having things read as they are printed is obviously useful,
is there cases when redirection to a pager may be a better idea sure,
but a lot of the time its useful.

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

yasr can already do this, I've considered maintaining it more
actively, and infact plan to since mgorse doesn't seem to be working
on it, but since its working fine for me, I haven't had much urgency
to work on that particular project.

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

uh, no yasr needs to run as root if and only if you need the login
prompt read, other wise its fine running as any user.  You are
confusing needs to be root to read file x and needs to be root period,
the first is true the second is not.

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

 You start a new shell on each tty what is the difference?  You could
also run screen and login on 1 tty.

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

THe only *real* problem I know of related to the user instance issue
is telling the library which server to connect to, which while a big
issue is one I think we know how to fix at this point.

Trev

> 
> Just my two cents.
> Halim
> 
> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd