On Fri, Jan 30, 2009 at 7:38 PM, Ken Schultz <schultz...@gmail.com> wrote:
>
> Any details/example how this is done?
>
> Ken
>

Hi Ken
Register a driver with one input node and export it.
Use the same input_dev variable as extern in second driver.

-- 
Best Regards
Pramod


> On Jan 29, 10:07 pm, pramod gurav <pramodfo...@gmail.com> wrote:
>> On Fri, Jan 30, 2009 at 6:46 AM, Ken Schultz <schultz...@gmail.com> wrote:
>>
>> > The problem I'm running into is how to do this in kernel space.  I
>> > would suspect you would need to share the input_dev struct between
>> > drivers so they each could call input_report_abs on the same
>> > input_dev, but since they are separate objects this makes it
>> > difficult.  Am I missing something simple here?
>>
>> Yes
>> the input_device structure variable can be accessed in between the drivers.
>> And I have seen both the drivers reporting correctly to the same
>> /dev/input.event#
>> node.
>>
>>
>>
>> > On Jan 29, 6:45 pm, Ken Schultz <schultz...@gmail.com> wrote:
>> >> Correction.  The other drivers would register to the input driver but
>> >> never write to their own event node.  Only the main driver would write
>> >> to its own event node.
>>
>> >> On Jan 29, 6:43 pm, Ken Schultz <schultz...@gmail.com> wrote:
>>
>> >> > So essentially the other drivers would register to the input driver
>> >> > but never write to it.  They would need to register so that the
>> >> > framework would can the poll function.  And the driver that is the
>> >> > owner of the /dev/input/event# being used would need to set all the
>> >> > input_set_abs_params(...., ABS_HAT0X,...,...) for every event type
>> >> > needed for the other drivers using the event node.
>>
>> >> > -Ken
>>
>> >> > On Jan 29, 6:23 pm, Mathias Agopian <pixelflin...@google.com> wrote:
>>
>> >> > > Hi  Ken,
>>
>> >> > > You can have several "entities" (be it drivers, or userspace code)
>> >> > > write into the *same* /dev/input/event#.
>>
>> >> > > Then, on the application side, the "data" sensor HAL module can read
>> >> > > from that /dev/input node, which it receives through the data_open()
>> >> > > "fd" parameter. There is no need to poll() several drivers.
>>
>> >> > > From userspace, for instance you can do something like:
>>
>> >> > > static int control__wake(struct sensors_control_context_t *dev)
>> >> > > {
>> >> > >     int err = 0;
>> >> > >     int fd = open_input(O_WRONLY);
>> >> > >     if (fd > 0) {
>> >> > >         struct input_event event[1];
>> >> > >         event[0].type = EV_SYN;
>> >> > >         event[0].code = SYN_CONFIG;
>> >> > >         event[0].value = 0;
>> >> > >         err = write(fd, event, sizeof(event));
>> >> > >         LOGD_IF(err<0, "control__wake, err=%d (%s)", errno, 
>> >> > > strerror(errno));
>> >> > >         close(fd);
>> >> > >     }
>> >> > >     return err;
>>
>> >> > > }
>>
>> >> > > This event will be received by whoever is reading from this event
>> >> > > node. Drivers can use the same strategy and push events into the same
>> >> > > event node.
>>
>> >> > > Mathias
>>
>> >> > > On Thu, Jan 29, 2009 at 4:17 PM, Ken Schultz <schultz...@gmail.com> 
>> >> > > wrote:
>>
>> >> > > > It seems the the sensors HAL can only reference a single /dev/input/
>> >> > > > event#, but if you have multiple sensor drivers how would you have
>> >> > > > them all reference the same event node?  Is this even possible?  I 
>> >> > > > was
>> >> > > > under the impression each input driver should have its own event 
>> >> > > > node.
>>
>> --
>> Best Regards
>> Pramod
> >
>

--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to