public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Henrik Rydberg" <rydberg@euromail.se>
To: Jeffrey Brown <jeffbrown@android.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] input: Set default events per packet.
Date: Mon, 28 Mar 2011 09:10:16 +0200	[thread overview]
Message-ID: <20110328071016.GA6863@polaris.bitmath.org> (raw)
In-Reply-To: <AANLkTi=KotXd4TyyUrhMdKn3mEq+pz2ac3Vnraa5udFh@mail.gmail.com>

> Originally, I set an arbitrary maximum bound of 20 slots.  In the
> interests of keeping it simple, I decided to remove that bound when I
> submitted the patch for review here.
> 
> How about:
> 
> mt_slots = min(MAX_MT_SLOTS_TO_INFER_FROM_TRACKING_ID_RANGE,
>    dev->absinfo[ABS_MT_TRACKING_ID].maximum -
> dev->absinfo[ABS_MT_TRACKING_ID].minimum + 1);
> 
> Where MAX_MT_SLOTS_TO_INFER_FROM_TRACKING_ID_RANGE is set to 32 or something.

Sure, 32 works for me.

> There's also the question of how many slots we should infer when
> neither ABS_MT_SLOT or ABS_MT_TRACKING_ID is available.  The drivers
> I've seen that don't provide tracking ids, are very basic and tend to
> only support 2 touch points.

There is the bcm5974 driver, but it sets its own limit, so 2 is fine.

> I guess we could add a DEFAULT_NUMBER_OF_MT_SLOTS constant to handle that case.
> 
> Please feel free to suggest better names for these constants.

With the same interest of keeping it simple in mind, inserting the
actual values is fine. We do not expect to duplicate the decisions
made in this function anywhere else.

Thanks,
Henrik

  reply	other threads:[~2011-03-28  7:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-23  1:04 [PATCH 0/4] input: Sizing the evdev ring buffer for MT devices and reporting overruns Jeff Brown
2011-03-23  1:04 ` [PATCH 1/4] input: Set default events per packet Jeff Brown
2011-03-25  8:20   ` Henrik Rydberg
2011-03-25 23:30     ` Jeffrey Brown
2011-03-28  7:10       ` Henrik Rydberg [this message]
2011-03-23  1:04 ` [PATCH 2/4] hid: hid-input: Remove obsolete default events per packet setting Jeff Brown
2011-03-23  1:04 ` [PATCH 3/4] input: evdev: Indicate buffer overrun with SYN_DROPPED Jeff Brown
2011-03-25  7:47   ` Dmitry Torokhov
2011-03-25  8:14   ` Henrik Rydberg
2011-03-25  9:02   ` Henrik Rydberg
     [not found]     ` <AANLkTike4c7SaeAm5JVWcLyZYt1K59OUEk94rnPeRkMy@mail.gmail.com>
2011-03-25 23:10       ` Jeffrey Brown
2011-03-25 23:12     ` Jeffrey Brown
2011-03-23  1:04 ` [PATCH 4/4] input: evdev: only wake poll on EV_SYN Jeff Brown
2011-03-25  7:49   ` Dmitry Torokhov
2011-03-25 23:03     ` Jeffrey Brown
2011-03-28  6:12       ` Dmitry Torokhov
2011-03-28  8:54         ` Jeffrey Brown
2011-03-25  8:34   ` Henrik Rydberg
2011-03-25 23:07     ` Jeffrey Brown

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=20110328071016.GA6863@polaris.bitmath.org \
    --to=rydberg@euromail.se \
    --cc=jeffbrown@android.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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