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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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 <[email protected]>
to Henrik's patch and take it through your tree together with the rest?
Thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
On Mon, Jun 14, 2010 at 4:49 AM, Henrik Rydberg <[email protected]> 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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
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