Bluetooth HID API

503 views
Skip to first unread message

Johan Zander

unread,
Mar 24, 2011, 9:41:18 AM3/24/11
to Android Contributors

I've seen that honeycomb will have official support for Bluetooth HID
but, looking at the API level 11, it doesn't look like an application
will be able to communicate directly with the device.
Would you accept a contribution that adds a new subclass BluetoothHID
to the BluetoothProfile interface?

Our product is a digital pen that is a non-keyboard/non-mouse device
and is accessed via the /dev/hidraw interface.


Jaikumar Ganesh

unread,
Mar 24, 2011, 12:44:28 PM3/24/11
to android...@googlegroups.com, Johan Zander, Jeff Brown, `...@google.com
Hi Johan:
   From Bluetooth perspective, its not a problem. A Bluetooth Pen should be able to pair and connect.

BluetoothHID APIs are not designed to have an app communicate with the input devices. All the input events are fed to the input framework (via Bluez / kernel) and the input framework handles it.

+Jeff Brown: If he is interested to accept any contributions to the input framework.

Johan Zander

unread,
Mar 24, 2011, 1:48:00 PM3/24/11
to Android Contributors
Thanks for the response,

Our goal is to be able to read/write on the two HID channels
(interrupt/control) from a Java application. Adding this via the
Bluetooth API was just my suggestion. Is it possible to access hid raw
data via the input framework already today or would it be better to
add the support there instead?

Also, when you say that a pen should be able to pair and connect - do
you mean on ginngerbread, honeycomb or gingerbread+omapzoom HID
modifications?

Best regards,
Johan

Petr Moravek

unread,
Mar 25, 2011, 1:18:27 PM3/25/11
to android...@googlegroups.com
Well,

it does not make much sense to have access to raw data from HID devices.
It is the same like touch gestures are fed as a gesture not as sequence of touches.
In addition platform dispatching of such input is always faster and could be accelerated.
It is like 4finger gestures on iPad which are now handled by apps but gonna be
handled by system in future.

There could two possible reasons to require direct access:
1. there exist some processing that is not done by system
2. there is need for acting as HID device, i.e. keyboard or mouse

Both reasons are wrong by concept. Both of them has something behind.
Each in fact is lack of logical API that links everything together.
In first case missing processing of raw data from HID device should be allowed
using some native library that extends the system through some defined way
i.e. system driver signed with a platform cert like it is done on Symbian.
The second should also be done rather by some api that allows linking
system keyaboard(on screen) link to kbd HID device emulation.

Petr
Reply all
Reply to author
Forward
0 new messages