mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Aleksey Kuleshov <rndfax@yandex.ru>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH 2/2] input: make the Input Core be the last in the poller queue
Date: Mon, 7 Mar 2016 08:30:16 +0100	[thread overview]
Message-ID: <20160307073016.GG21869@pengutronix.de> (raw)
In-Reply-To: <4230541457086688@web17h.yandex.ru>

On Fri, Mar 04, 2016 at 01:18:08PM +0300, Aleksey Kuleshov wrote:
> Hi Sascha,
> 
> 04.03.2016, 10:19, "Sascha Hauer" <s.hauer@pengutronix.de>:
> > 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2016-03-07  7:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-03 15:17 [PATCH 1/2] poller: allow safely remove pollers in any time Aleksey Kuleshov
2016-03-03 15:17 ` [PATCH 2/2] input: make the Input Core be the last in the poller queue Aleksey Kuleshov
2016-03-04  7:19   ` Sascha Hauer
2016-03-04 10:18     ` Aleksey Kuleshov
2016-03-07  7:30       ` Sascha Hauer [this message]
2016-03-07  9:16         ` Aleksey Kuleshov
2016-03-10  9:26           ` Sascha Hauer
2016-03-11 12:25             ` Aleksey Kuleshov
2016-03-11 14:51               ` Sascha Hauer
2016-03-11 15:12                 ` Aleksey Kuleshov
2016-03-14 16:26             ` Aleksey Kuleshov
2016-03-16  7:17               ` Sascha Hauer
2016-03-03 16:54 ` [PATCH 1/2] poller: allow safely remove pollers in any time Antony Pavlov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160307073016.GG21869@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=rndfax@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox