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... -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
