[BRLTTY] cursor routing slow when using brltty in gnome/mate-terminal

[Samuel Thibault]

Hello,

I've had a look at why cursor routing is quite slow when using
brltty for reading gnome/mate-terminal (both using libvte for the
implementation). Brltty measures 25ms delay between requesting the arrow
simulation and seeing cursor movement, and then it waits for as much
time in case more of this happens, before pressing the next key.

A good part of the 25ms is the forwarding of the event (I didn't measure
it all along): it goes over dbus to the registry (~2ms), gets translated
to an X event and sent to the X server (~1ms), it is received by the
terminal, sent to the tty, received by the application, interpreted by
the application, cursor movement is requested by the application to
the tty, received by the terminal. But then... the terminal buffers
this, and waits for 10ms (VTE_DISPLAY_TIMEOUT), in case something else
happens. Only then it sends the cursor-moved event over at-spi, directly
to brltty.

So, to summarize: the processing being quite heavy is part of the
slowness, but it can't be compressed (by using e.g. dbus-broker) below
10ms anyway. Which means that anyway at best a 40-characters display can
be wholy-routed in about 1 second :/

I know that brltty is waiting for cursor movement feedback in order to
be as robust as possible.  I wonder if there could be a user-tunable
parameter to make it just emit all keypresses and wait for the result?

Samuel