On Fri, Mar 04, 2016 at 01:18:08PM +0300, Aleksey Kuleshov wrote:
> Hi Sascha,
>
> 04.03.2016, 10:19, "Sascha Hauer" <s.hauer@xxxxxxxxxxxxxx>:
> > On Thu, Mar 03, 2016 at 06:17:10PM +0300, Aleksey Kuleshov wrote:
> >> This prevents the case when Input Core and event providers
> >> have to run "at one time" so Input Core will work with non-relevant
> >> data since it will be called first.
> >> ---
> >> drivers/input/input.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > I tested the approach to add a .poll callback into struct input_device
> > and to let the input core register one poller for all input devices
> > rather than one poller for each device. This also gives the input core
> > better control when the input devices are polled. Would that approach go
> > into the right direction?
>
> I don't understand the rules of "drivers/input/*".
>
> All drivers register themselves as pollers? It seems yes.
Yes, currently they do. Since all drivers do this and all drivers *must*
do it as there is no interrupt support, this could equally well be done
by the input core instead of the drivers.
>
> All drivers should be regular polled? No, because, for example, USB keyboard
> should be polled once per N ms.
>
> All drivers could be polled per some-driver-specific N ms? Yes.
> For example, one USB keyboard asks for 10 ms, the other - for 5 ms.
That's some adhoc value. Could be 5ms, 10ms, there's probably no good
reason for one or the other. It must be somewhere between not-too-often
to not slow down barebox and not-too-seldom to not introduce noticable
delays in the reaction to the keys.
>
> What about GPIO keyboards? Can they be polled once per N ms?
> It seems "why not?".
>
> So we have some pollers with, for example, 5ms, 10ms and regular callings.
> Do you want to handle this inside the Input Core?
Yes, but all should have the same timeout.
>
> --------------------------------
> Or may be it will be enough to poll every driver per 10 ms? Actually, why not?
> If that's the case, then your approach is in the right direction.
ok
>
> Anyway, you will still have to do async call for repeating keys - and that's
> 400ms for the first press event, and then 40ms for subsuquent.
>
> So, I guess, you will have two "poller_register" in Input Core (input.c):
> 1) for 10ms polling drivers - "driver poller";
> 2) for key repeating - "repeat poller".
Not necessarily. It could be one poller which does something like:
if (is_timeout(last_time, 10 * MSECOND))
/* Not too often */
return;
last_time = get_time_ns();
for_each_input_device(idev) {
if (status_changed(idev)) {
/* first key press */
idev->repeat_timeout = 400 * MSECOND;
idev->repeat = get_time_ns();
send_key(idev);
} else if (is_timeout(idev->repeat, idev->repeat_timeout)) {
/* repeat key press */
send_key(idev);
idev->repeat = get_time_ns();
}
}
>
> Just make sure that "driver poller" registers first and after it you register "repeat poller".
> --------------------------------
>
>
> > I have no ready-to-post patch for this approach, partly because it doesn't
> > solve the double-return problem and I currently don't understand why.
>
> The whole problem of double-return is here:
>
> static void input_console_repeat(void *ctx)
> {
> struct input_console *ic = ctx;
>
> if (ic->current_key) {
> kfifo_putc(ic->fifo, ic->current_key);
> poller_call_async(&ic->poller, 40 * MSECOND,
> input_console_repeat, ic);
> }
> }
>
> This function is ASYNC. All what you have to do is to make sure that
> this function gets called AFTER all input-driver-providers will be polled.
I thought that aswell and thought I should have fixed this issue in my
patch, but it didn't work as expected so there's still something wrong,
either in my thoughts or in my implementation.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
