On Tue, May 18, 2010 at 7:19 AM, Pavan Savoy wrote:
> On Tue, May 18, 2010 at 6:35 PM, Greg KH wrote:
>> On Mon, May 17, 2010 at 10:58 PM, sunil pillai
>> 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
On Tue, May 18, 2010 at 6:35 PM, Greg KH wrote:
> On Mon, May 17, 2010 at 10:58 PM, sunil pillai
> 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 obvi
On Mon, May 17, 2010 at 10:58 PM, sunil pillai
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 p
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 f
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 res
On Fri, May 14, 2010 at 4:30 AM, Sunil Pillai 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
>
> |
>
Hi All,
I've a typical requirement for presenter hid device.
[Diagram below]
=
User Space
|
i/p sub system
|
hid class driver
|- * [Pass hid report
|
