[BRLTTY] BRLTTY and AT-SPI

[Aura Kelloniemi]

Hi, and thank you for the quick reply!

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:

 > Aura Kelloniemi, le Fri 28 Aug 2015 23:55:53 +0300, a écrit :
>> - BRLTTY does not correctly detect the terminal size (it tries to guess it by
>>   examining line lengths, but this fails). Because of this the cursor is often
>>   out of BRLTTY's knowledge.

 > Could you provide reproducible test cases?

Sure, my .xinitrc looks like this:

### BEGIN .xinitrc:
#!/bin/bash
for f in /etc/X11/xinit/xinitrc.d/*; do
  [ -x "$f" ] && . "$f"
done
unset f

export GTK_MODULES=gail:atk-bridge
export SAL_USE_VCLPLUGIN="gtk"
export GNOME_ACCESSIBILITY=2
/usr/bin/xbrlapi &
/usr/bin/orca &
sleep 2 # THis is annoying, but necessary
/usr/bin/brltty -b ba -x a2 -ne -l 7 > /tmp/brl 2>&1 &
/usr/bin/lxterminal &
exec lxsession
### END .xinitrc

Now when lxde starts, I sometimes need to press ALT-TAB so that BRLTTY notices
which window is active. Then the display shows my bash prompt, because that's
the only thing on the terminal screen. But the cursor is not shown, because
its position is the length of the terminal text string (acquired from D-Bus by
BRLTTY) plus one. So if I now type any leter or space, and then backspace or
arrow left, the cursor appears, because its position is now between 0 and the
terminal text string length (esclusive).

>> - Sometimes BRLTTY shows line-feed (\r) characters instead of breaking lines

I can't reproduce this right now, but it happens often. I will report this
when I notice it.

>> - Sometimes BRLTTY shows incorrect text (text that has already disappeared
>>   from the visual window)

 > That may be bugs in the terminal itself actually.  Again, reproducible
 > testcase would be useful, otherwise I don't really know where to look
 > at.

In lxterminal I run emacs -nw, and then almost any BRLTTY command will display
something that is not on the screen, including previous commands typed, etc.
Running the HOME command returns BRLTTY to display expected thigs again.

This seems to be terminal-dependent though, because this problem does not
appear to be present in roxterm.

>> - BRLTTY and Orca are having a hard time deciding which one has the control of
>>   the braille display - for example Orca should take precedence in menus,
>>   while BRLTTY should display the actual terminal widget.

 > You can tell brltty which widgets it should take control of with
 > -X type=terminal

Sometimes this does not work, and Orca takes over the braille display
entirely, or then Orca's braille output is lost completely.

>> - BRLTTY does not support copy/paste

 > I'm surprised, this should already be working, either from the brltty
 > running the linux driver, or through xbrlapi.

>> or cursor routing in its AT-SPI driver

 > I'm surprised, IIRC cursor routing is independent from the screen reader
 > actually, it's the core which tries to move the cursor.

Yes, but cursor movement and copy/paste require support from the driver - the
driver must be able to emulate key presses, and this apparently is not
supported by the AT-SPI2 driver.

>> - Immediate key presses (those defined in key table with !) don't work in
>>   brlapi - commands activated by immediate key presses are only run every
>>   second time the key is pressed.

 > I don't know what immediate key presses are. That probably explains why
 > they're not working correctly.