Mathias,
I am looking to use the cupcake version of sensors.h for the sensor
HAL
layer.
>In "theory", all you need to do is implement a sensor HAL module
>properly (as documented in sensors.h. pay extreme attention to the
>definition of the axis and units). Unfortunately, in the current git
>rep
Hi all,
I am in the process of writing a sensors HAL based on the new cupcake
module structure. One restriction of the sensors HAL is that there
can only be a single input device used for all sensors. Can anyone
provide any assistance and/or example on how this might be done with
multiple kerne
It seems the the sensors HAL can only reference a single /dev/input/
event#, but if you have multiple sensor drivers how would you have
them all reference the same event node? Is this even possible? I was
under the impression each input driver should have its own event node.
--~--~-~--~-
event
> node. Drivers can use the same strategy and push events into the same
> event node.
>
> Mathias
>
> On Thu, Jan 29, 2009 at 4:17 PM, Ken Schultz wrote:
>
> > It seems the the sensors HAL can only reference a single /dev/input/
> > event#, but if you have m
Correction. The other drivers would register to the input driver but
never write to their own event node. Only the main driver would write
to its own event node.
On Jan 29, 6:43 pm, Ken Schultz wrote:
> So essentially the other drivers would register to the input driver
> but never wr
imple here?
On Jan 29, 6:45 pm, Ken Schultz wrote:
> Correction. The other drivers would register to the input driver but
> never write to their own event node. Only the main driver would write
> to its own event node.
>
> On Jan 29, 6:43 pm, Ken Schultz wrote:
>
> > So
Any details/example how this is done?
Ken
On Jan 29, 10:07 pm, pramod gurav wrote:
> On Fri, Jan 30, 2009 at 6:46 AM, Ken Schultz wrote:
>
> > The problem I'm running into is how to do this in kernel space. I
> > would suspect you would need to share the input_dev str
Does anyone know the best touchscreen resolution for Android? Most
likely there would be a sweet spot for this. The higher the
resolution the more data which could cause a bottleneck for data flow
and the low the resolution the worse the accuracy is. I would imagine
this to be in the units pixe
Is there a recommended way to pass information between a
sensors_control_context_t struct and a sensors_data_context_t struct?
(i.e. active_sensors) For devices without a hardware eCompass there
needs to be a way in the polling function to determine if the sensor
is activated, so it can inject da
