linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: Daniel Mack <daniel@caiaq.de>, linux-input@vger.kernel.org
Subject: Re: [PATCH] Input: rotary_encoder cleanup
Date: Wed, 8 Jul 2009 21:17:51 -0700	[thread overview]
Message-ID: <20090709041751.GA10415@dtor-d630.eng.vmware.com> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190901A689B9@mi8nycmail19.Mi8.com>

On Wed, Jul 08, 2009 at 05:47:07PM -0400, H Hartley Sweeten wrote:
> On Tuesday, July 07, 2009 11:57 PM, Dmitry Torokhov wrote:
> > On Wed, Jul 01, 2009 at 02:45:58PM -0400, H Hartley Sweeten wrote:
> >> On Wednesday, July 01, 2009 11:34 AM, Daniel Mack wrote:
> >>> On Tue, Jun 30, 2009 at 11:56:36AM -0400, H Hartley Sweeten wrote:
> >>>> On Monday, June 29, 2009 7:32 PM, Dmitry Torokhov wrote:
> >>>>> Do we know how many encoders we need to have in the system to start
> >>>>> seeing the benefits (given that all these conversions increase text
> >>>>> size)?
> >>>> 
> >>>> Hmm.. Didn't think about that. How do you determine the text size?
> >>> 
> >>> 'objdump -h'?
> >> 
> >> Thanks.
> >> 
> >>>> I am trying to work out a clean way to pass an array of encoders
> >>>> from the platform init file so that multiple devices can be handled
> >>>> by the driver.  That was what prompted the change.
> >>> 
> >>> Hmm, and then report them all via the very same input device? Or
> >>> register one for each encoder? The latter could easily be done by
> >>> registering multiple platform_devices with different platform_data,
> >>> right?
> >> 
> >> I suppose each encoder could be registered individually.  Then each
> >> would report as a unique input device.  This should work with the
> >> driver as it is now.  Then drawback is if there are a number of
> >> encoders and a userspace app is opening all of them and doing a
> >> EVIOCGRAB it makes the app a bit messy.
> >> 
> >> I was thinking more or passing an array of encoders to the driver and
> >> then having it report all of them as one input device.  That ends up
> >> being a lot cleaner.
> >>
> >
> > Hmm, what axis will they be reporting though? Seems like very
> > specialized [ab]use if they all share the same input device...
> 
> Each encoder reports as a unique axis.  They just all share one input
> device.
> 

Well, if they truly represent X and Y axes then sharing the same input
device is proper. However if you are using single input just to simplify
userspace application and events reported do not really represent
movement for the axis specified - that would be bad.

-- 
Dmitry

  reply	other threads:[~2009-07-09  4:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-20 22:15 [PATCH] Input: rotary_encoder cleanup H Hartley Sweeten
2009-06-23 16:21 ` Daniel Mack
2009-06-30  2:32   ` Dmitry Torokhov
2009-06-30 15:56     ` H Hartley Sweeten
2009-07-01 18:33       ` Daniel Mack
2009-07-01 18:45         ` H Hartley Sweeten
2009-07-01 18:49           ` Daniel Mack
2009-07-07 18:32             ` H Hartley Sweeten
2009-07-08  6:56           ` Dmitry Torokhov
2009-07-08 21:47             ` H Hartley Sweeten
2009-07-09  4:17               ` Dmitry Torokhov [this message]
2009-07-09 16:31                 ` H Hartley Sweeten

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=20090709041751.GA10415@dtor-d630.eng.vmware.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=daniel@caiaq.de \
    --cc=hartleys@visionengravers.com \
    --cc=linux-input@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;
as well as URLs for NNTP newsgroup(s).