[BRLTTY] BRLTTY and AT-SPI

Aura Kelloniemi spammi.helevetti at nbl.fi
Sun Aug 30 16:40:03 EDT 2015


Hello

Samuel Thibault <samuel.thibault at ens-lyon.org> writes:
 > Aura Kelloniemi, le Sat 29 Aug 2015 01:14:43 +0300, a écrit :
>> >> - 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.

I managed to produce this in two ways in gnome-terminal and roxterm:

First way:
1. View a file in less. The file should be longer than one screenful.
2. Press the right arrow key. The screen is scrolled left and the less prompt
  changes from the file name to a single colon.
3. Now press arrow key down. On my braille display, second colon appears so
  that there are now two colons visible.
4. In no particular order press right and down again repeatedly and many more
  colons get appended to the braille cursor line.

Second way:
1. Run cat with no arguments.
2. Press space, then backspace repeatedly and sometimes the cursor stops
  moving on the braille display. Orca still notices cursor movement and the
  added characters, so the problem must be in BRLTTY. Space is the only
  character which with this behaviour can be demonstrated, other chars don't
  cause it.

There isn't anything special in the log, just caret moves, inserts and deletes
in either case.

>> 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.

 > I can't manage to reproduce this.

For some reason it happens for me all the time (in lxterminal at least). Orca
works perfectly though. Sometimes this happens in gnome-terminal
and roxterm too. Often it can be seen by scrollin (with BRLTTY commands) past
the end of screen. When I use the INFO mode I see that sometimes BRLTTY thinks
that the terminal has 48 lines (even though it has only 24).

>> - When using the AT-SPI2 driver there is no cursor tracking. For some reason
>>   the display does not follow the cursor, even though cursor tracking is on.

 > This is working for me, at least what I understand what cursor tracking
 > is.

It now works in git head, most likely because of your fixes, thanks.

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

 > Does that happen in lxterminal? I would consider that a bug of
 > lxterminal that it sends \r characters, it's really not supposed to
 > exist in the terminal representation (and can only bring mess)

Sorry, it was a thinko, I really meant line-feed (\n). I saw this in
gnome-terminal today, but can't reproduce it.

Cursor routing works now often. However, there is some weird behaviour that I
see when looking at the debug logs. Here is what happens when a use cursor
routing:

brltty: command: 000118 (ROUTE: bring screen cursor to character #25)
brltty: program exit event added: cursor-routing
brltty: end of term :1.7:/org/a11y/atspi/accessible/83
brltty: SPI2 stopped
brltty: :1.7 /org/a11y/atspi/accessible/83 is focused!
brltty: state changed focused to role terminal
brltty: new term :1.7:/org/a11y/atspi/accessible/83 with text [snip...]
brltty: 24 rows
brltty: 48 cols
brltty: Got caret 48
brltty: SPI2 initialized
brltty: inserting key: F804 -> 65361
brltty: unknown signal org.freedesktop.DBus NameAcquired
brltty: caret move to 47
brltty: caret move to 47
brltty: invalid screen area: cols=48 left=0 width=49 rows=24 top=0 height=1
brltty: end of term :1.7:/org/a11y/atspi/accessible/83
brltty: SPI2 stopped

Sometimes the cursor routing stops prematurely.

Copy/paste works now, but is quite slow as is cursor routing.

I also discovered one more bug. Sometimes the cursor is visible in the INFO
mode when using the brlapi braille driver. Steps to reproduce:
1. Use brlapi braille driver.
2. Invoke HOME so that cursor is visible
3. Activate INFO mode (with no status cells in use) and the cursor is still
   visible, even though the info text is shown on the display.

Thank you so much for your support!

-- 
Aura


More information about the BRLTTY mailing list