Thanks Greg. I know the the information I posted was not enough informative. But I think with the queries you have raised, I can take it forward from here. Thanks a lot for that.
1. Firstly to be clear I'm actually dealing with a HID Host, which is a
bluetooth host. This HOST receives BT packets from a wireless HID device
like a keyboard, mouse etc.
2. However the HOST BT stack in this case is a userspace stack. So the HOST
here gets the BT packet which is parsed by the stack and it gets USB HID
CLASS REPORT after passing it to L2CAP & stripping off the BT Packets.
*Note: *"Above scenario is same as Bluez which is in kernel. In case of
Bluez once the BT packet is parsed by the stack (as in 2 above), the USB HID
CLASS REPORT is then parsed by Bluez's own USB HID CLASS Report parser
called HIDP. It becomes straight forward for Bluez since both the BLUETOOTH
STACK & HIDP Module (usb hid class parser) are in kernel space"
3.* But in my case:*
a. Firstly the BT packet received by host is processed by
the user-space Bluetooth stack. so after the stack processes the packet the
USB HID CLASS REPORT is in user space.
b. Secondly, I don't want to come with my own parser (unlike Bluez), but
instead use the generic USB HID Class driver support of the kernel to parse
by the USB HID CLASS reports. This USB HID CLASS driver, as far I see,
looks very closely coupled with the usb driver. (Might be this is why Bluez
have its own USB HID Class Report parser)
How do i handle this scenario. Points (3.a) & (3.b) are exactly where my
requirement differs from Bluez implementation of the same scenario.
*Note:*
1. * *So I hope it's clear that userspace is not creating any hid event. We
are still talking about USB HID REPORTS received in the userspace BT stack.
2. So I hope it makes it obvious now that once my userspace BT stack parses
the BT packet and gets the USB HID CLASS REPORT, it needs to be sent to the
kernel for further parsing.
Please let me know if I'm still obscure in putting things into words.
--Sunil
Firstly, "hid report" quoted by me refers to the USB HID CLASS report. I'm
getting this USB HID CLASS REPORT from my Bluetooth stack which happens to
be to be in user space.
Lets consider here the bluez architecure and how it actually handles a
similar scenario. Please correct me if I'm wrong some where [?]
On 18 May 2010 05:10, 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<android-kernel%2bunsubscr...@googlegroups.com>
> website: http://groups.google.com/group/android-kernel
--
-
(¨`•.•´¨) Always
`•.¸(¨`•.•´¨) Keep
(¨`•.•´¨)¸.•´ Smiling!!
`•.¸.•´
Cheers´¨)Sunil
¸ •´ ¸.•*´¨) ¸.•*¨)
(¸.•´ (¸.•* ♥♥♥...♪♪♪
--
unsubscribe: android-kernel+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-kernel<<330.gif>>
