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:

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...
 
-- 
Dmitry