[BRLTTY] Slowness of some brltty commands

Dave Mielke dave at mielke.cc
Tue Mar 1 09:56:43 EST 2016


[quoted lines by payman shaykhmehdi on 2016/03/01 at 16:35 +0330]

>I think I have used default timeouts, the only timeout value that I have
>used in braille display driver is the input of probeBrailleDisplay()
>function (==1000).

Okay. That timeout is for how long to wait for a response to an identity probe.

>readBraillePacket() function have been used for reading packets from
>device. There is no such delay for DOT keys or keys that are mapped to
>Desktop keyboard keys (e.g KEY_BACKSPACE, KEY_CURSOR_UP, ...) but when I
>press keys that are bounded to FWINT, braille display reacts slowly.

That shouldn't be. Is it possible that the actual difference is between key(s) 
that take your fingers away from the display versus key(s) that let you leave 
your fingers on the display? In other words, it's possible that key(s) that 
take your fingers away from the display are simply perceived to be faster due 
to the time it takes you to get back to the display.

>Is it reasonable to say that because keys such as DOTs and KEY_BACKSPACE
>don't execute any command, brltty can handle them faster and so updates
>braille display faster?

No, because even those keys ultimately invoke commands. Tehre is a difference, 
though. Dots, keyboard key emulation, etc result in a screen update to which 
brltty responds. Commands like FWINLT/RT, on the other hand, don't result in a 
screen update so brltty needs to schedule a display refresh. Maybe there's 
something in that timing that you're noticing.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: Dave at Mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/


More information about the BRLTTY mailing list