[BRLTTY] Keypad bindings and copy buffer

[Dave Mielke]

[quoted lines by Nicolas Pitre on 2012/08/10 at 09:00 -0400]

Hi:

>The counterpart to this is that it might be slightly harder for the core to 
>determine without any doubt if consecutive events are really the product of a 
>device initiated key auto-repeat feature, whereas in the driver this might be 
>obvious if for example a release and a press events are found back to back in 
>the same communication block.

They wouldn't necessarily be in the same block. Some devices only send one USB 
packet per event. Over Bluetooth and serial, there's no such thing as the same 
block. The bytes take time to transmit, so there's a time delay anyway.

>To solve this in a generic way would entail time stamping everything that is 
>passed over to the core so that all events to come together over the wire get 
>the same time stamp.  And the time stamping would have to be done at the 
>driver level or any task preemption between two event reports to the core 
>would introduce time skews.
>
>Maybe the ad hoc per driver solutions can be avoided by simply providing 
>a common filtering facility that drivers have the option to use or not.

There already is one. It's the core function enqueueKeyEvent(). The only real 
difficulty (from an efficiency perspective) is flushing a pending release if no 
other event causes that function to be called for a while.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | 2011 May 21 is the End of Salvation.
EMail: dave at mielke.cc | Canada  K2A 1H7   | http://Mielke.cc/now.html
http://FamilyRadio.com/                   | http://Mielke.cc/bible/