Latest Debian snapshot

[Kerry Hoath]

Handshaking with the dectalk express has allways been a problem; in fact 
asap would lock up nicely if you used the type command to read a long text 
file.

Whilst I understand the desire to send multiple killobytes of text to the 
synth and have speakup do the right thing it raises some interesting points.

the scrollback buffer is finite; and most sighted people pipe to a pager 
rather than shift pageup especially if the text is long.

I have no idea whether speakup supports the kernel scrollback buffer which 
relys on storing text in spare video memory.
I do know however that screen's scrollback buffer does in deed work.
This brings up an interesting question regarding how speakup and Linux 
should behave regarding handshaking.

When the synthesizer indicates buffer full, rts goes low and the software 
sending text should supposedly stop generating synthesizer output.

Ok so what do you do from a Linux perspective? Block console output until 
the synth raises rts?
How long should that blokc happen for? 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?
How long should this process take given that people run their synthesizers 
at different speeds?

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

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.
I also notice many cables for the dectalk distress either have bad wiring or 
the firmware in the device doesn't even handshake reliably.
regards, Kerry.

----- Original Message ----- 
From: "Tony Baechler" <tony at baechler.net>
To: "Speakup is a screen review system for Linux." <speakup at braille.uwo.ca>
Sent: Friday, July 25, 2008 6:04 PM
Subject: Re: Latest Debian snapshot


Gaijin wrote:
> On Thu, Jul 24, 2008 at 09:00:11AM -0700, Tony Baechler wrote:
>
>> Apparently there is a scrollback buffer in the kernel
>> but I never got it to work.
>>
>
> Do you know about the 'script' command that will copy all screen
> I/O to a file?  Run without parameters, script will log everything  to a
> file in the current directory called "typescript".  Use the "exit"
> command to exit console logging.
>



Yes, that isn't what I'm interested in.  There's screen (1) as well,
which in combination with script (1) lets you have multiple windows
open.  One can also direct logs and such to tty7 and read them with
Alt+F7 from the console.  I was specifically interested in a scrollback
buffer that is apparently supposed to be part of the kernel and wouldn't
require redirecting to a file like you suggest with script (1).  One
doesn't always know how much output will be generated when running a
command and often one finds out too late that speech stops and text will
not be spoken which has scrolled off the screen.  A good example is when
I cat a README file.  I don't need to make a typescript because it's
already a file on disk.  I don't really want to reread the file with
more (1) when only a small amount of text wasn't spoken.  A scrollback
buffer would be ideal.  Besides, I don't want typescripts taking up
large amounts of disk space and I don't want to keep a record of every
command with output for security and privacy reasons.  The .bash_history
is bad enough.  Thanks anyway for the suggestion though.  That is a good
idea when upgrading so you can see if anything went wrong and what.
_______________________________________________
Speakup mailing list
Speakup at braille.uwo.ca
http://speech.braille.uwo.ca/mailman/listinfo/speakup