[BRLTTY] introduction

[kendell clark]

hi
One thing I've just noticed. I just rebuilt our brltty package for
sonar. During the configure step, brltty is warning it can't find
speech-dispatcher. I'm assuming it needs it's headers. Arch doesn't
provide separate header packages like debian and fedora do, but the
headers are placed in /usr/include/speech-dispatcher. Is there a way I
can help brltty find it so I can set speech-dispatcher as an available
driver? The plan is to eventually have brltty use the sd driver as
default, so if the user changes orca settings, brltty will keep up. If
that doesn't work out I'll fall back to the espeak driver.
Thanks
Kendell Clark


kendell clark wrote:
> hi
> Pressing kp_Enter+kp5 didn't speak. One interesting thing I'm noticing
> is that when I switch to a virtual console, brltty is killed. I see
> messages from systemd indicating that brltty exited with status signal.
> I'll correct the config file. I was under the mistaken impression that
> the ba driver was what was needed for use with orca, but I guess it
> connects to brltty on it's own, it doesn't need to be explicitly
> enabled? One last thing. I'm used to speakup's method of navigation.
> That is, you use the number pad to read by line, word and character. Is
> there a brltty keyboard table with similar bindings? If so, I'll enable
> this so that users of sonar who are used to speakup are at least
> somewhat familiar with it.
> Thanks
> Kendell Clark
>
>
>
> Dave Mielke wrote:
>> [quoted lines by kendell clark on 2016/03/19 at 12:15 -0500]
>>
>>> Ok, debug log is attached. 
>> eSpeak is initializing correctly. I see nothing in the log showing that brltty 
>> is trying to actually say something, though. This may be because that's its 
>> default behaviour. As a quick test to see if it can actually speak, try (with 
>> the keypad keyboard table enabled) pressing KPEnter+KP5. That'll explicitly 
>> tell it to speak the current line.
>>
>> Another aspect of brltty's default behaviour is that it'll speak if no braille 
>> driver is running. What you may be experiencing, therefore, is that it's 
>> initially speaking up until, but not after, it manages to start a braille 
>> driver.
>>
>> I'm guessing that you must be specifying: braille-driver auto,ba
>>
>> The auto operand only works if it's specified by itself. That's why you're 
>> seeing a failure to load the "auto" braille driver library. Such a thing 
>> doesn't exist, but, since you're specifying more possible drivers, it's 
>> interpreting "auto" as an actual driver.
>>
>> I wouldn't specify "ba" (the BrlAPI braille driver) as a driver to try within a 
>> default configuration. In fact, this is why a braille driver is eventually 
>> started, and, therefore, why you may be losing speech.
>>
>> You're correct that you do want BrlAPI active, but not as a braille driver. 
>> What you want is BrlAPI to be active as a server, and that's the default 
>> behaviour. The BrlAPI braille driver is for communicating with a second 
>> instance of brltty.
>>
>>> How would you run pulse audio as a system daemon? I've read up on this on the 
>>> arch wiki, but I've also heard there are some security risks with doing so. 
>> I've never looked up what their security worries are. One thing that I can 
>> think of, though, is that it may allow anyone to send audio to the speakers. 
>> Even worse might be that someone else could theoretically activate your 
>> microphone and listen in on you. I myself don't worry about such things, 
>> especially since control to Pulse Audio, even when running as a system daemon, 
>> is controlled by membership in the ulse-access user group.
>>
>>> However, if this will make it easier to have brltty speak, I'll make it the 
>>> default on sonar. 
>> I tend to agree. Since they do have security concerns, though, you may want to 
>> look up what they are, and then to accompany your stuff with an appropriate 
>> warning.
>>
>>> The idea is to be able to switch back and forth between the console and x 
>>> session without difficulty. 
>> This may require a bit of X reconfiguration since, by default, it starts its 
>> own Pulse Audio server. This creares a race condition between your system-wide 
>> daemon and the one X starts. If X starts its server first then yours won't be 
>> able to start. It'd be best, therefore, to explicitly tell X not to start its 
>> own.
>>
>> More on you not having an actual braille display:
>>
>> Brltty supports a couple of test braille drivers: XWindow [xw], and TTY {tt]. 
>> The XWindow driver creates a virtual braille display within an X window. The 
>> TTY driver creates a virtual braille display using your serial port.
>>
>> If, therefore, you have either one of those (now ancient) serial port computer 
>> terminals or a second computer on which you can run a tool like minicom, you 
>> can emulate having an actual braille device.
>>