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
next prev parent 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