Greg,

I think the scenario is similar to AVRCP of bluetooth or when there is
a user-space bluetooth stack, which implements HID protocol.
Wireless mouse/keyboard would send HID events to user-space daemons
listening on connection, and the events/key-strokes needs to be
broadcasted/let-known to rest of system..

Or even say case of IR - a "proprietary" IR stack and daemon listening
onto connection and receiving HID inputs.

I guess his quetion is simple, if for any case HID events end up being
in user-space, how does it let know the rest of the system (via the
input subsystem) ??

regards,
Pavan

On Tue, May 18, 2010 at 5:10 AM, Greg KH <gre...@gmail.com> wrote:
> On Fri, May 14, 2010 at 4:30 AM, Sunil Pillai <sunilpillai....@gmail.com> 
> wrote:
>>
>>
>>
>> Hi All,
>>
>> I've a typical requirement for presenter hid device.
>
> That's not "typical" at all.  What is causing this requirement?
>
>> [Diagram below]
>> =============
>>
>>        User Space
>> ____________________________
>>              |
>>      i/p sub system
>>              |
>>      hid class driver
>>              |----------------- * [Pass hid report
>>              |                     coming from user space]
>>              |
>>              |
>>         usb driver
>>
>> My requirments are as follows:
>> 1. In userspace I have hid reports, which needs to be parsed. These
>> hid reports needs to be sent to android input event manager, via
>> kernel (strict requirement)
>
> Why is this "strict"?  What is generating these hid events?  Userspace?
> Ick, why would userspace ever want to generate a HID event when it can
> generate the proper input events directly from userspace without all the
> mess of the HID layer.
>
> And you are aware of the patent issues regarding HID events and
> userspace, right?  If not, please go do some research, or you might get
> in trouble later on...
>
>> 2. Basically once the hid report comes to kernel (via some means,
>> hiddev interface, char driver interface etc), this needs to be sent to
>> the hid class driver for parsing
>
> Again, why a HID event?
>
>> 3. Further hid class driver will take care of parsing it and sending
>> it to user space via i/p subsystem.
>>
>> In need help to design the module marked * (in the above diagram).
>
> I think you need to push back on the "design" :)
>
>> Doubts:
>>
>> 1. What kind of an interface I can have here to get hid reports from
>> user space.
>
> None.  Don't do that.  Seriously.  It's crazy.
>
>> 2. How do I then send this reports to hid class driver for parsing
>> (register with which module)
>
> If #1 is not done, then you don't have to do #2 so you are happy :)
>
> What is the real, root, problem that you are trying to handle here?
>
> And again, be _very_ aware of the patent issues surrounding HID events,
> some companies take them _very_ seriously.
>
> good luck,
>
> greg k-h
>
> --
> unsubscribe: android-kernel+unsubscr...@googlegroups.com
> website: http://groups.google.com/group/android-kernel



-- 
--Pavan Savoy

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

Reply via email to