Latest Debian snapshot

Samuel Thibault samuel.thibault at ens-lyon.org
Fri Jul 25 07:06:37 EDT 2008


Hello,

I guess it may have to go somewhere in the documentation.

Kerry Hoath, le Fri 25 Jul 2008 18:49:37 +0800, a écrit :
> I have no idea whether speakup supports the kernel scrollback buffer which 
> relys on storing text in spare video memory.

It doesn't currently, due to kernel interface limitations.

> Ok so what do you do from a Linux perspective? Block console output until 
> the synth raises rts?

That is what we are doing currently, by stopping the consoles (just like
if you pressed control-S or the scroll lock key).

> How long should that blokc happen for?

Until the synth has eaten some data

> What if rts never goes high again?
> Should the console freeze forever thereby introducing the possibility of a 
> denial of service attack or should speakup give up and assume synth not 
> present?

Speakup currently does the latter: after a few "full_time" timeouts,
speakup considers the synth to be dead, and thus restart the consoles.

> How long should this process take given that people run their synthesizers 
> at different speeds?

Interesting question, I guess full_time should take into account the
speed.

> Does the screen stop scrolling for a sighted person and does the console 
> file descriptor ever block for them?

Yes.

> I certainly would like to see the problem solved; however the problem is not 
> as simple as blocking console output when the synthesizer handshakes off.

It is not simple indeed, but it's implemented and does work to our
knowledge (William usually tests it with his ltlk for instance).  We
haven't yet figured out why it doesn't for the dectalk express.

> I also notice many cables for the dectalk distress either have bad wiring or 
> the firmware in the device doesn't even handshake reliably.

That would explain it.

Samuel



More information about the Speakup mailing list