Hi all.
I'm currently working on a HID Over GATT Implementation (HID over Bluetooth Low energy).
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.
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.
Thanks for your assistance,
Chen Ganir
Texas Instruments.
From: David Herrmann <hidden> Date: 2012-03-14 16:52:44
Hi Chen
On Wed, Mar 14, 2012 at 12:47 PM, Ganir, Chen [off-list ref] wrote:
Hi all.
I'm currently working on a HID Over GATT Implementation (HID over Bluetooth Low energy).
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".
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?
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.
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.
Thanks for your assistance,
Chen Ganir
Texas Instruments.
Hi David/Chen:
On Wed, Mar 14, 2012 at 1:47 PM, David Herrmann
[off-list ref] wrote:
Hi Chen
On Wed, Mar 14, 2012 at 12:47 PM, Ganir, Chen [off-list ref] wrote:
quoted
Hi all.
I'm currently working on a HID Over GATT Implementation (HID over Bluetooth Low energy).
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.
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?
quoted
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.
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.
How does hidraw interfaces with the userspace?
BR,
Claudio
From: Joao Paulo Rechi Vita <hidden> Date: 2012-03-15 20:27:21
Hello all,
On Thu, Mar 15, 2012 at 5:06 PM, Claudio Takahasi
[off-list ref] wrote:
Hi David/Chen:
On Wed, Mar 14, 2012 at 1:47 PM, David Herrmann
[off-list ref] wrote:
quoted
Hi Chen
On Wed, Mar 14, 2012 at 12:47 PM, Ganir, Chen [off-list ref] wrote:
quoted
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.
quoted
quoted
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.
quoted
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.
quoted
quoted
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.
quoted
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Herrmann <hidden> Date: 2012-03-15 21:40:56
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
[off-list ref] wrote:
Hello all,
On Thu, Mar 15, 2012 at 5:06 PM, Claudio Takahasi
[off-list ref] wrote:
quoted
Hi David/Chen:
On Wed, Mar 14, 2012 at 1:47 PM, David Herrmann
[off-list ref] wrote:
quoted
Hi Chen
On Wed, Mar 14, 2012 at 12:47 PM, Ganir, Chen [off-list ref] wrote:
quoted
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.
quoted
quoted
quoted
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.
quoted
quoted
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.
quoted
quoted
quoted
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.
quoted
quoted
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.
quoted
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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?
After reading the followup discussion, I don't think I have any
fundamental objections to the overall principle proposal.
Thanks,
--
Jiri Kosina
SUSE Labs