[PATCH] hid-input: Use a larger event buffer for MT devices

[PATCH] hid-input: Use a larger event buffer for MT devices

[Henrik Rydberg]

The MT devices produce a lot of data. Tell the underlying input device
approximately how many events will be sent per synchronization, to allow
for better buffering. The number is a template based on continuously
reporting details for each finger on a single hand.

Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
Hi Jiri,

This patch goes together with the evdev buffer patchset, which Dmitry
is going to queue for 2.6.36.

Cheers,
Henrik

 drivers/hid/hid-input.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 7a0d2e4..69d152e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -534,6 +534,9 @@ mapped:
 			input_set_abs_params(input, usage->code, a, b, (b - a) >> 8, (b - a) >> 4);
 		else	input_set_abs_params(input, usage->code, a, b, 0, 0);
 
+		/* use a larger default input buffer for MT devices */
+		if (usage->code == ABS_MT_POSITION_X && input->hint_events_per_packet == 0)
+			input_set_events_per_packet(input, 60);
 	}
 
 	if (usage->type == EV_ABS &&
-- 
1.6.3.3

Re: [PATCH] hid-input: Use a larger event buffer for MT devices

[Jiri Kosina]

On Mon, 14 Jun 2010, Henrik Rydberg wrote:

> The MT devices produce a lot of data. Tell the underlying input device
> approximately how many events will be sent per synchronization, to allow
> for better buffering. The number is a template based on continuously
> reporting details for each finger on a single hand.
> 
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Jiri,
> 
> This patch goes together with the evdev buffer patchset, which Dmitry
> is going to queue for 2.6.36.

So it makes sense to take it together with the rest of the patchset to 
avoid syncing problems between the trees.

Dmitry, could you please add

	Signed-off-by: Jiri Kosina <jkosina@suse.cz>

to Henrik's patch and take it through your tree together with the rest?

Thanks.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [PATCH] hid-input: Use a larger event buffer for MT devices

[Ping Cheng]

On Mon, Jun 14, 2010 at 4:49 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> The MT devices produce a lot of data. Tell the underlying input device
> approximately how many events will be sent per synchronization, to allow
> for better buffering. The number is a template based on continuously
> reporting details for each finger on a single hand.
>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Jiri,
>
> This patch goes together with the evdev buffer patchset, which Dmitry
> is going to queue for 2.6.36.
>
> Cheers,
> Henrik
>
>  drivers/hid/hid-input.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 7a0d2e4..69d152e 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -534,6 +534,9 @@ mapped:
>                        input_set_abs_params(input, usage->code, a, b, (b - a) >> 8, (b - a) >> 4);
>                else    input_set_abs_params(input, usage->code, a, b, 0, 0);
>
> +               /* use a larger default input buffer for MT devices */
> +               if (usage->code == ABS_MT_POSITION_X && input->hint_events_per_packet == 0)
> +                       input_set_events_per_packet(input, 60);

Do we really want to use a hardcoded number here? Considering you have
used the same value in your "input: bcm5974" patch, adding it as an
ifdef in linux/input.h should not be an overkill in design and offers
the other drivers a chance to use it.

Ping

>        }
>
>        if (usage->type == EV_ABS &&
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH] hid-input: Use a larger event buffer for MT devices

[Ping Cheng]

On Mon, Jun 14, 2010 at 4:49 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> The MT devices produce a lot of data. Tell the underlying input device
> approximately how many events will be sent per synchronization, to allow
> for better buffering. The number is a template based on continuously
> reporting details for each finger on a single hand.
>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Jiri,
>
> This patch goes together with the evdev buffer patchset, which Dmitry
> is going to queue for 2.6.36.
>
> Cheers,
> Henrik
>
>  drivers/hid/hid-input.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 7a0d2e4..69d152e 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -534,6 +534,9 @@ mapped:
>                        input_set_abs_params(input, usage->code, a, b, (b - a) >> 8, (b - a) >> 4);
>                else    input_set_abs_params(input, usage->code, a, b, 0, 0);
>
> +               /* use a larger default input buffer for MT devices */
> +               if (usage->code == ABS_MT_POSITION_X && input->hint_events_per_packet == 0)
> +                       input_set_events_per_packet(input, 60);

Do we really want to use a hardcoded number here? Considering you have
used the same value in your "input: bcm5974" patch, adding it as an
ifdef in linux/input.h should not be an overkill in design and offers
the other drivers a chance to use it.

Ping

>        }
>
>        if (usage->type == EV_ABS &&
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hid-input: Use a larger event buffer for MT devices

[Henrik Rydberg]

Ping Cheng wrote:
[...]
> Do we really want to use a hardcoded number here? Considering you have
> used the same value in your "input: bcm5974" patch, adding it as an
> ifdef in linux/input.h should not be an overkill in design and offers
> the other drivers a chance to use it.

Well, I think it is. The fact that it appears more than once rather points to
the general duplication between HID and special input devices. A function like
"input_device_needs_more_bandwidth()" would be clean, but it just does not seem
worth it.

Henrik