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:

quoted

On Wed, Jul 01, 2009 at 02:45:58PM -0400, H Hartley Sweeten wrote:

quoted

On Wednesday, July 01, 2009 11:34 AM, Daniel Mack wrote:

quoted

On Tue, Jun 30, 2009 at 11:56:36AM -0400, H Hartley Sweeten wrote:

quoted

On Monday, June 29, 2009 7:32 PM, Dmitry Torokhov wrote:

quoted

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.

quoted

quoted

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