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. >> >> 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. >> >> 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? > 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. Thanks a lot, -- João Paulo Rechi Vita Openbossa Labs - INdT -- 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
