From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from SMTP.EU.CITRIX.COM (smtp.ctxuk.citrix.com [62.200.22.115]) by speech.braille.uwo.ca (Postfix) with ESMTP id 33E24109BE for ; Fri, 25 Jul 2008 07:06:38 -0400 (EDT) X-IronPort-AV: E=Sophos;i="4.31,252,1215388800"; d="scan'208";a="1164442" Received: from lonpexchmx01.citrite.net ([10.30.224.191]) by LONPIPO01.EU.CITRIX.COM with ESMTP; 25 Jul 2008 11:06:37 +0000 Received: from implementation.famille.thibault.fr ([10.80.12.250]) by lonpexchmx01.citrite.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Jul 2008 12:06:37 +0100 Received: from samy by implementation.famille.thibault.fr with local (Exim 4.69) (envelope-from ) id 1KML89-0002bQ-UX for speakup@braille.uwo.ca; Fri, 25 Jul 2008 13:06:37 +0200 Date: Fri, 25 Jul 2008 12:06:37 +0100 From: Samuel Thibault To: "Speakup is a screen review system for Linux." Subject: Re: Latest Debian snapshot Message-ID: <20080725110637.GL4482@implementation.uk.xensource.com> References: <20080724131849.GA19925@investigative.net> <20080724134711.GV4755@implementation.uk.xensource.com> <4889A526.50108@baechler.net> <000601c8ee44$22197660$2518a8c0@bouncy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <000601c8ee44$22197660$2518a8c0@bouncy> User-Agent: Mutt/1.5.12-2006-07-14 X-OriginalArrivalTime: 25 Jul 2008 11:06:37.0514 (UTC) FILETIME=[81EF8AA0:01C8EE46] X-BeenThere: speakup@braille.uwo.ca X-Mailman-Version: 2.1.10 Precedence: list Reply-To: "Speakup is a screen review system for Linux." List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 11:06:38 -0000 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