[BRLTTY] Using the Orbit Reader 20 with BRLTTY and Orca

[Nolan Darilek]

Actually, I just commented out the setting to use ttyACM0, restarted the 
systemd service, put the unit in HID mode, and I now get "screen not in 
text mode" under X, and output on the console. Neat. Guess I was a bit 
too zealous in trying to configure things.


When you ask if I'm using Orca's BRLTTY driver, what specifically do you 
mean? I don't see an option in Orca's settings to select a specific 
driver, nor do I see anything obvious in `orca --help`. Where do I learn 
which driver I'm using? Braille support is enabled from the screen 
reader preferences GUI. That, plus a few generic options like Grade 2, 
are all I see in that screen.


Thanks for the detailed response.


On 6/6/19 9:46 AM, Dave Mielke wrote:
> [quoted lines by Nolan Darilek on 2019/06/05 at 18:10 -0500]
>
>> Hey, just picked up one of these recently and had a few questions. I've
>> gotten it intermittently working with BRLTTY,
> What, exactly, is being intermittent? When it works, does everything work? When
> it doesn't work, does nothing at all work? How often does it work versus fail?
>
>> but not at all with Orca.
> Perhaps you aren't telling Orca to use brltty as its braille driver. Perhaps
> the BrlAPI interface isn't properly enabled. Guessing is never good. We'd need
> to see a log.
>
>> 1. The Orbit has two modes that seem relevant to BRLTTY use:: Serial and HID.
>> I assume I want to use serial mode?
> Both should work, assuming, of course, that you're using the Bam (bm) driver.
>
>> 2. What is the process for using the Orbit with BRLTTY if I'll be plugging
>> and unplugging it fairly regularly? Specifically:
>>
>> a) I'm using BRLTTY with systemd. Can I leave the service running,
>> connect/disconnect the unit, and expect to have that change noticed? Or will
>> I need to restart the service whenever reconnecting?
> If you have the latest brltty udev rules installed properly, and if you have
> the latest brltty systemd units installed properly, then you just need to
> connect/disconnect your braille device. Assumimg a USB connection, the acts of
> connecting and disconnecting the braille deivce will automatically take care of
> starting and stopping brltty.
>
>> b) Do I need to do something on the unit itself, other than
>> connecting/starting the unit, to get output?
> No, you shouldn't need to. Of course, you'll need to ensure that it isn't in
> some sort of internal use mode and that it's configured to use the I/O method
> that you're connecting it with.
>
>> I'm getting an alert about the screen not being in text mode, which makes
>> sense since I'm in X.
> Yes. Try switching to a text console in order to verify that brltty itself is
> indeed working correctly.
>
>> But I only get that message sometimes, and it doesn't always appear after I've
>> plugged in the unit, enabled serial mode, and restarted the systemd service.
> I'm not willing to guess. We need to figure out exactly what is and isn't
> working. Please capture a debug log. You can do this most easily by adding two
> command line options when invoking brltty. They are:
>
>     -ldebug,brldrv,inpkts,outpkts,usb
>     -L/path/to/logfile
>
> Note that the first -l is lowercase and that the second -L is uppercase.
>
>> c) Can BRLTTY handle its configured device node appearing/disappearing?
> Yes.
>
>> 3. My unit seems to use /dev/ttyACM0, not /dev/ttyUSB0. What does ACM mean in
>> this context?
> The ttyUSB devices are for various (usually older) USB to serial adapters. The
> ttyACM devices are for the ones that conform to the ACM (Abstract Control
> Model) subclass of the CDC (Communication Device Class). This newer standard is
> generic, and, therefore, a bit more complex so it presents the serial adapter
> to the system in a way that's different enough to warrant its own kernel
> driver.
>
> Now I'm getting the idea that you're asking brltty to use its serial I/O
> paradigm, i.e. something like serial:ttyACM0, which won't adequately interact
> with systemd. It'd be better, I think, to tell brltty to access the device via
> USB directly, i.e. specifying usb: (yes, the trailing colon is necessary).
> That's what brltty's udev rules would do automatically for you.
>
>> 4. How do I use BRLTTY with Orca? I'm on Fedora 29. I've installed the brlapi
>> package and added:
>>
>> api-parameters Auth=group:brlapi        # Allow some local group
>>
>> and my user is in the brlapi group.
> But is Orca running as a process which can be a member of that group.
>
> When trying to figure this sort of thing out, it's best to simplify the usage
> first and then slowly, one step at a time, getting back to where you want to
> be. That, for example, is why, above, I suggested that you first verify that
> brltty is working correctly within a text console. For this case, my suggestion
> is to first try with auth:none.
>
> You may also wish to consider using BrlAPI's polkit support.
>
>> I've enabled Braille in Orca, and have restarted.
> Have you set Orca's braille driver to brltty?
>
>> 5. I see lots of this in my logs. What does it mean?
>>
>> Jun 05 18:06:00 desktop systemd[1]: Starting Braille display driver for Linux/Unix...
> That's when systemd is starting brltty.
>
>> Jun 05 18:06:00 desktop brltty[18771]: BRLTTY 5.6 rev unknown [http://brltty.com/
> And that's brltty actually starting. The "unknown" means that brltty was built
> outside of a git source tree so the build couldn't figure out which revision of
> the source was being used.
>
>> Jun 05 18:06:00 desktop brltty[18771]: BRLTTY 5.6 rev unknown [http://brltty.com/]
> If you're actually seeing this twice then it's because one is from brltty
> logging its banner to the system log and the other is brltty writing its banner
> to the console (which systemd must be including within its journal).
>
>> Jun 05 18:06:00 desktop systemd[1]: Started Braille display driver for Linux/Unix.
> That's systemd confirming that brltty has been started.
>
>> Jun 05 18:06:00 desktop brltty[18772]: NoSpeech Speech Driver:
> That means that you aren't using any of brltty's speech drivers.
>
>> Jun 05 18:06:04 desktop brltty[18772]: Ignored Byte: 1B
>> Jun 05 18:06:04 desktop brltty[18772]: Ignored Byte: 34
>> Jun 05 18:06:04 desktop brltty[18772]: Ignored Byte: 04
>> Jun 05 18:06:04 desktop brltty[18772]: Ignored Byte: 1B
>> Jun 05 18:06:04 desktop brltty[18772]: Ignored Byte: 34
> This is the braille driver ignoring Baum-style packets, which is making me
> wonder if you're using a different driver.
>