[BRLTTY] 5.0 has been released.

[Nicolas Pitre]

On Mon, 27 Jan 2014, Dave Mielke wrote:

> BRLTTY-5.0 has been released.

[...]

> The most significant change in this release is that brltty is now event-based 
> rather than polling-based.

Kudos to Dave for this achievement.

This may seem trivial to the uninitiated, especially as nothing really 
changed on the surface when using BRLTTY.  But this still means major 
and non-trivial changes to the way BRLTTY operates internally.  As I 
helped Dave with some issues in the course of this development, I was 
able to appreciate the extent of the effort Dave has put into this.

Why is this so important if nothing has changed on the surface?  In 
short, this has to do with power management and battery life.

Previously, BRLTTY would go to sleep for 40 milliseconds, then wake up 
to inspect the screen content and the braille display keys in case 
something changed, perform the necessary braille content update, and go 
back to sleep for another 40 milliseconds, and wake up again, etc.  In 
programming jargon this way of doing things is called "polling".  The 
main advantage of polling is a much simpler program since polling is 
very easy to implement.  It is also much easier to debug as everything 
is performed always in the same sequence all the time. However, polling 
comes in the way of power management which wasn't much of an issue when 
BRLTTY was initially developed almost 20 years ago.

Designers of today's laptops and portable devices like Android phones 
and tablets are doing anything they can to make batteries last longer 
while still making the batteries themselves as small as possible to keep 
the size and weight of the device down.  One solution for reducing power 
consumption consists of simply shutting down the processor when there is 
nothing to do.  For example, when your smart phone is done redrawing the 
screen with some web page content, it may well simply turn itself off to 
save power while still keeping the screen on.  As soon as the screen is 
touched, a key pressed, or if a call comes in, then the processor is 
quickly booted up again and execution resumes where it left in order to 
react to the new event.

Those processor shutdown and wake-up operations are good for saving 
power overall, but they take some time to perform, sometimes in the 
order of a few milliseconds.  And those operations do consume some 
amount of extra power as well.  As you might start to realize, BRLTTY's 
40-millisecond polling loop is not helping power consumption at all if 
it forces the processor to wake-up, shutdown, wake-up, shutdown, and so 
only to notice that the screen content has not changed and no keys were 
pressed on the braille display in most cases.  Not only this has the 
potential to increase power consumption, but the processor ends up 
spending a significant amount of time simply suspending and resuming 
itself instead of doing useful work.

To mitigate this effect, power saving measures such as suspending the 
processor are applied only when the system has been doing absolutely 
nothing for a little while.  But if BRLTTY is running its poll loop 25 
times per second then this never makes the system appear idle enough for 
power saving features to kick in. So it was time for BRLTTY to adapt to 
the modern world and behave appropriately.  Hence the new "event based" 
mode of operation.

In short, this means that BRLTTY now tells the operating system what 
events it is interested in, and simply goes to sleep until one of those 
events is signaled.  If no events are signaled, BRLTTY simply doesn't 
wake up at all and the processor may shut itself down for a much longer 
period while you are reading the braille display content.  Simple, 
right?

Actually this is not so simple.  Event based programming, unlike polling 
based programming, must react to any event in any order at any time in 
any random sequence.  This makes the program much more complex and prone 
to subtle bugs we call "races".  For example a race may occur if the 
processing of an event requires various pieces of information and 
another event changed some of that information half through.

A concrete example of a race that we had to identify, and then deal 
with, broke auto-speak and keyboard echo.  When the Linux console 
receives a new character when you press a key on the keyboard, then the 
kernel performs two distinct operations.  First it draws that character 
on the screen at the cursor location, and then it moves the cursor one 
position to the right.  The way screen update events are signaled by the 
kernel, you get notified twice by the kernel in this case.  When this 
happens on a multi-processor system, the kernel could be doing the 
screen update on one CPU at the same time BRLTTY is processing signaled 
events on another CPU.  If BRLTTY sees both events together it does see 
a new character being typed and perform character echo normally.  But if 
it sees the new character first and sends the speech request for that 
character, and then sees the cursor moving to a blank position next to 
that character just like when arrow keys are used and mutes the speech 
synthesizer in that case, the end result becomes a very random keyboard 
echo where some key presses are pronounced and some are not.

This race existed before BRLTTY became event based of course, but the 
odds of BRLTTY executing its poll loop right in the middle of this 
screen update sequence were extremely low.  Now that BRLTTY is able to 
react at the very moment a change occurs, the timing is much more likely 
to be right.  And yet, this is true on some systems and not on others 
depending on the CPU speed and other variables which sometimes makes 
reproduction of this type of problem by a developer very difficult.

This is not the only race or issue that needed attention of course.  
Many other funny behaviors which cause was subtle and unexpected 
appeared and were fixed. And the code had to be rearchitected to fit the 
event based programming model in the first place, etc.

Simply to say that Dave did a great job and has put a lot of efforts in 
this work over several months so that BRLTTY appears to just work as 
before, with the indirect but still well appreciated side effect of 
prolonging the battery life of your laptop or portable device.  I 
therefore wanted to give you all a sense of the significance the 5.0 
release has for justifying a major version number bump, even if nothing 
revolutionary over the previous release is presented to the casual user.

So thank you Dave for your dedication to this project.
This is highly appreciated.


Nicolas