Thanks greg & pavan for your valuable insights. I was not able to directly make use of uinput, since my hid reports had to be parsed first by the HID Parser driver, before giving it to the input subsystem.
Anyways, thanks a ton to the maintainer of HID-CORE module, Jiri Kosina. I'm just quoting below a abstract of her response to this thread: " some time ago I have rewritten the whole HID subsystem, so that HID handling (parsing) is completely independent from the transport protocol used (Bluetooth, USB). This has been in kernel from 2.6.26 or so. There is shared HID infrastructure in drivers/hid, and there are two low-level implementations, which share this common infrastructure -- USB (in drivers/hid/usbhid) and Bluetooth (net/bluetooth/hidp)" Hope this would help someone facing the same situation some time. Thanks once again.....all you guys. On May 18, 7:57 pm, Greg KH <gre...@gmail.com> wrote: > On Tue, May 18, 2010 at 7:19 AM, Pavan Savoy <pavan.sa...@gmail.com> wrote: > > On Tue, May 18, 2010 at 6:35 PM, Greg KH <gre...@gmail.com> wrote: > >> On Mon, May 17, 2010 at 10:58 PM, sunil pillai > >> <sunilpillai....@gmail.com> wrote: > >>> 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. > > >> Ok, that makes sense. > > >> But why not just use the Bluez Bluetooth stack instead of your own? > >> That would solve your problem, right? > > >> If not, then you will need to add such an interface to the kernel, if > >> the input maintainers accept it. But note that you are doing something > >> that duplicates an already-present functionality in the kernel, you will > >> probably not get it accepted. > > > Greg, > > > Would usage of uinput in this case makes sense ? > > Uinput I suppose is for such purposes right ? > > Yes, that is what I hinted at back at my very first > response :) > > thanks, > > greg -h > > -- > unsubscribe: android-kernel+unsubscr...@googlegroups.com > website:http://groups.google.com/group/android-kernel -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
