On Fri, 10 Aug 2012, Dave Mielke wrote: > [quoted lines by Nicolas Pitre on 2012/08/10 at 00:11 -0400] > > >I was thinking about adding this overhead to the Alva driver only. If > >no other device is having this issue, this is probably not worth adding > >this complexity to the core. > > But it's the kind of problem that could arise any time with any device. I > believe, therefore, that resolving it centrally would be best. I'm also of > the > opinion that, wherever possible, solutions should be centralized so that, as > we've seen in the past, each driver won't develop it's own, ad hoc, usually > error prone solution.
Fair enough. 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. 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. Nicolas _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
