[BRLTTY] missing key release events, was Re: brltty5.2 alpine2.11 cursor tracking

[Nicolas Pitre]

On Wed, 7 Oct 2015, Dave Mielke wrote:

> [quoted lines by Nicolas Pitre on 2015/10/07 at 14:28 -0400]
> 
> >BTW, I instrumented the code to see the effect of those PCM efficiency 
> >patches I sent you.  Generating 100000000 samples and discarding them 
> >from within writePcmData() takes 14 seconds on my PC.  Doing the same 
> >with my 2 patches applied brings that down to 9 seconds. I suspect the 
> >relative difference would be even bigger on portable devices.
> 
> I'm still trying to understand one line in the "division -> shift" change.

Let's see:

-    int32_t positiveShiftsPerQuarterWave = INT32_MAX / 8;
+    int32_t positiveShiftsPerQuarterWave = 1 << (16 + 12);

This is a value with the same magnitude, except the first is 0x0fffffff 
and the second is 0x10000000. So only a difference of 1 between them.

-    int32_t amplitudeGranularity = positiveShiftsPerQuarterWave / maximumAmplitude;

This is the x/y slope invert constant.  Further on:

-    int32_t actualAmplitude = normalizedAmplitude / amplitudeGranularity;
+    int32_t actualAmplitude =
+              ((normalizedAmplitude >> 12) * maximumAmplitude) >> 16;

Here we have actualAmplitude = normalizedAmplitude / amplitudeGranularity.
That can be transformed as follows:

-> normalizedAmplitude / amplitudeGranularity

-> normalizedAmplitude / (positiveShiftsPerQuarterWave / maximumAmplitude)

-> normalizedAmplitude * maximumAmplitude / positiveShiftsPerQuarterWave

-> normalizedAmplitude * maximumAmplitude / (1 << 28)

-> (normalizedAmplitude * maximumAmplitude) >> 28

Of course the product would overflow 32 bits here. Given that 
maximumAmplitude is already limited to 15 bits, and the result must fit 
in 31 bits (plus the sign bit totalling 32 bits), that means that 
normalizedAmplitude must be scaled down to 16 bits before the product. 
Hence the >> 12 in the patched code.  And finally, this signed 32-bit 
result must be scaled down to a signed 16 bit value, which explains the 
final >> 16 in the patched code.

This is why I used 1 << (16 + 12) to initialize 
positiveShiftsPerQuarterWave just to make the bit split more obvious.


Nicolas