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@xxxxxxxxxxxx> 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
