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.
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.
On Thu, Mar 24, 2011 at 18:48, Johan Zander <johanzan
...@gmail.com> wrote:
> 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
> On 24 mar, 17:44, Jaikumar Ganesh <jaiku...@google.com> wrote:
> > 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.
> > On Thu, Mar 24, 2011 at 6:41 AM, Johan Zander <johanzan...@gmail.com>
> wrote:
> > > 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.