Hi Joao Jiri, maybe you can comment on this. We are trying to provide hid_ll_drivers from user-space to implement BT-HIDP for BT-low-energy. My idea is to write an uinput-like interface which allows to register hid_ll_drivers from userspace. Do you have any objections here? On Thu, Mar 15, 2012 at 9:27 PM, Joao Paulo Rechi Vita <jprvita@xxxxxxxxxxxxx> wrote: > Hello all, > > On Thu, Mar 15, 2012 at 5:06 PM, Claudio Takahasi > <claudio.takahasi@xxxxxxxxxxxxx> wrote: >> Hi David/Chen: >> >> On Wed, Mar 14, 2012 at 1:47 PM, David Herrmann >> <dh.herrmann@xxxxxxxxxxxxxx> wrote: >>> Hi Chen >>> >>> On Wed, Mar 14, 2012 at 12:47 PM, Ganir, Chen <chen.ganir@xxxxxx> wrote: >>>> Hi all. >>>> >>>> I'm currently working on a HID Over GATT Implementation (HID over Bluetooth Low energy). >>>> > > We're also working to support the HoG here at INdT. > >>>> As part of the design, it is required to configure the HID subsystem from user space, configure a report descriptor with input/output/feature report points, and send/receive data from and to the kernel HID Subsystem, from user space. >>>> >>>> Is there anything already supporting this feature ? I was looking at hid-raw, but it is used to send raw data from user space to the hid device - I need to send raw hid from the device to the kernel. >>> >>> What do you mean with that? hidraw uses the >>> hid_input/output_raw_report() callbacks which HIDP/USBHID provide. >>> They provide direct access to the HID channels. With the >>> Bluetooth-backend you can directly write to the L2CAP channels. I >>> don't understand what you mean with "device to the kernel". >> >> HoG encapsulates HID reports using ATT protocol. The userspace needs >> to transcode the data and send back to the kernel. >> There isn't dynamic L2CAP channel allocation for Bluetooth Low Energy. >> Only one fixed data channel is allowed, and more than one profile can >> be exposed by the remote: services have a shared channel. >> > > Trying to make it more clear: there is only one L2CAP socket for all > low energy data exchanged between the host and the remote device. Data > for different services/profiles is multiplexed and encapsulated on the > ATT protocol on the same socket. Since we don't want to move the ATT > parser inside the kernel, the plan is to extract HoG traffic from this > socket on the userspace, reconstruct regular HID reports, and send > them back to the kernel to be handled by the HID/input subsystems. Thanks for clarifying that. I now understand what you are planning to do. >>> >>> Do you need something more low-level or more high-level? Currently, >>> HIDP/USBHID provide the transport layer and register themselves with >>> the HID core. The HID core parses the HID protocol and provides input >>> devices on top of it. I don't understand where in-between of this you >>> want the hooks to be? >>> > > We want something that works similar to HIDP and USBHID, the only > difference is that it needs to be able to receive/send HID > input/output reports to the userspace instead of to a hw device. > >>>> Our basic idea was to develop a new misc char driver, at /dev/uhid. This device will be opened for each remote device we have access to, configured, and then read/write the raw HID packets from the device directly to this driver. We would like our solution to be a simple proxy between the device and the HID system, and we do not want to include a HID parser in our code, to make sure latency stays as low as possible. > > I personally don't think HID parsing on the userspace would add much > latency, but duplicating this code on the userspace is definitely > something we want to avoid. Agreed. Personally I think rewriting the HID parser wouldn't be much work but it also wouldn't buy us anything. We eventually would feed the input via uinput into the kernel anyway so we do not save any round-trips here. So feeding it directly into the HID system seems legit to me. >>> >>> Does that mean you want to sit on top of the kernel HID parser or you >>> don't want any parser in between? /dev/uhid looks like a HID-backend >>> like HIDP/usbhid so hidraw seems to be perfect for this. >> > > We want something that behaves exactly like uinput, but that also does > HID parsing. Is there something on the input subsystem that behaves > like that? No. What you need is to write a hid_ll_driver which accepts input from user-space. The HID system takes input from low-level drivers (hid_ll_driver) like HIDP and USBHID and creates input devices on top of it. There is currently no way to write hid_ll_drivers in user-space, however, it should be easy to write one. I am CC'ing Jiri Kosina (HID Maintainer) and Dmitri to go sure they don't know any other way of dealing with this. I will have a look at this and try to write a short uinput-like driver for HID if you are interested in this. >> How does hidraw interfaces with the userspace? >> > > Does hidraw covers the use-case I've tried to describe here? It's > documentation was a bit confusing to me, any clarification will be > very helpful. No, I am sorry, hidraw is definitely not what you need here. > Thanks a lot, > > -- > João Paulo Rechi Vita > Openbossa Labs - INdT Regards David -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
