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.
If two encoders are reporting on the same axis they would have to be
on different input devices.
I was hoping to pass something like this to the rotary_encoder driver
from my platform init:
static struct rotary_encoder_platform_data my_rotary_encoder_info[] = {
{
.gpio_a = GPIO_ROTARY1_A,
.gpio_b = GPIO_ROTARY1_B,
.axis = REL_X,
.relative_axis = true,
}, {
.gpio_a = GPIO_ROTARY2_A,
.gpio_b = GPIO_ROTARY2_B,
.axis = REL_Y,
.relative_axis = true,
}, {
.gpio_a = GPIO_ROTARY3_A,
.gpio_b = GPIO_ROTARY3_B,
.axis = REL_Z,
.relative_axis = true,
}, {
.gpio_a = GPIO_ROTARY4_A,
.gpio_b = GPIO_ROTARY4_B,
.axis = ABS_THROTTLE,
.steps = 1024,
.rollover = false,
.relative_axis = false,
},
( 0 }
};
static struct platform_device rotary_encoder_device = {
.name = "rotary-encoder",
.id = 0,
.dev = {
.platform_data = my_rotary_encoder_info,
},
};
The rotary_encoder_probe() function would then just loop thru the
plaform_data and OR in either BIT_MASK(EV_REL) or BIT_MASK(EV_ABS)
as appropriate and either set the input->relbit[0] or call
input_set_abs_params() for the axis.
I just need to figure out a way to pass the correct cookie to the
irq function so that the right axis is processed.
Does this sound resonable?
Regards,
Hartley
--
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
