Re: SHR-U Accelerometer data

2009-12-18 Thread Iain B. Findleton
Iain B. Findleton wrote:
> Michael 'Mickey' Lauer wrote:
>   
>> Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton:
>>   
>> 
>>> Many tests appear to indicate that a complete report set read from
>>> /dev/input/event2 or event3 is a relative rarity. Looking at the code
>>> from the lis302dl driver in git.openmoko.org it appears to me that this
>>> should not be true, and if I recall correctly, proper output was couming
>>> out under OM2009.x at one point.
>>> 
>>>   
>> Let me remind you that the driver has changed wrt. RELATIVE and
>> ABSOLUTE. These days, upon opening the device, only the first report is
>> a full report. Subsequent reports only contain changed axes.
>>   
>> 
> I got that about the ABSOLUTE. The changes only thing does not look to
> come from
> the driver code. Is that something associated with the linux input
> system interface?
>   
>>   
>> 
>>> Anybody with any thoughts on this issue? According to what I read,
>>> /dev/input/eventx interface should reliably handle every event and make
>>> it available.
>>>
>>> The other issue is that the first report from the driver following an
>>> open on the device should be complete and contain the axis calibration
>>> values. This appears to be not true in that the first report I get is
>>> often incomplete in that not all axes are supplied.
>>> 
>>>   
>> I can't confirm that. I'm running andy-tracking and when I call hexdump
>>  the first three entries are always axes 0, 1, 2.
>>
>>   
>> 
> >From what I saw of the driver code and the lis302dl spec sheet, an open
> on the device
> file should send the calibration data from the device. Can you confirm
> that I am reading the correct driver source?
>
>   
I have now confirmed that indeed the proper sequence of data is flowing
from the accelerometer
interface using /dev/input/event2 and event3. The first 64 bytes after
an open contain the calibration values and the next 64 bytes contain the
complete absolute readings. Subsequent events only contain changed values.

Thanks for the responses.

> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: SHR-U Accelerometer data

2009-12-17 Thread Neil Brown
On Thu, 17 Dec 2009 12:32:46 -0500
"Iain B. Findleton"  wrote:

> > Let me remind you that the driver has changed wrt. RELATIVE and
> > ABSOLUTE. These days, upon opening the device, only the first report is
> > a full report. Subsequent reports only contain changed axes.
> > 
> I got that about the ABSOLUTE. The changes only thing does not look to
> come from
> the driver code. Is that something associated with the linux input
> system interface?

Yes - for absolute events, the linux input layer only forwards them when they
change.

You can get the current values at any time using an 'ioctl'.
EBIOCGABS returns a 'struct input_absinfo' - see /usr/include/linux/input.h

NeilBrown

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: SHR-U Accelerometer data

2009-12-17 Thread Iain B. Findleton
Michael 'Mickey' Lauer wrote:
> Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton:
>   
>> Many tests appear to indicate that a complete report set read from
>> /dev/input/event2 or event3 is a relative rarity. Looking at the code
>> from the lis302dl driver in git.openmoko.org it appears to me that this
>> should not be true, and if I recall correctly, proper output was couming
>> out under OM2009.x at one point.
>> 
>
> Let me remind you that the driver has changed wrt. RELATIVE and
> ABSOLUTE. These days, upon opening the device, only the first report is
> a full report. Subsequent reports only contain changed axes.
>   
I got that about the ABSOLUTE. The changes only thing does not look to
come from
the driver code. Is that something associated with the linux input
system interface?
>   
>> Anybody with any thoughts on this issue? According to what I read,
>> /dev/input/eventx interface should reliably handle every event and make
>> it available.
>>
>> The other issue is that the first report from the driver following an
>> open on the device should be complete and contain the axis calibration
>> values. This appears to be not true in that the first report I get is
>> often incomplete in that not all axes are supplied.
>> 
>
> I can't confirm that. I'm running andy-tracking and when I call hexdump
>  the first three entries are always axes 0, 1, 2.
>
>   
>From what I saw of the driver code and the lis302dl spec sheet, an open
on the device
file should send the calibration data from the device. Can you confirm
that I am reading the correct driver source?


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: SHR-U Accelerometer data

2009-12-17 Thread Michael 'Mickey' Lauer
Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton:
> Many tests appear to indicate that a complete report set read from
> /dev/input/event2 or event3 is a relative rarity. Looking at the code
> from the lis302dl driver in git.openmoko.org it appears to me that this
> should not be true, and if I recall correctly, proper output was couming
> out under OM2009.x at one point.

Let me remind you that the driver has changed wrt. RELATIVE and
ABSOLUTE. These days, upon opening the device, only the first report is
a full report. Subsequent reports only contain changed axes.

> 
> Anybody with any thoughts on this issue? According to what I read,
> /dev/input/eventx interface should reliably handle every event and make
> it available.
> 
> The other issue is that the first report from the driver following an
> open on the device should be complete and contain the axis calibration
> values. This appears to be not true in that the first report I get is
> often incomplete in that not all axes are supplied.

I can't confirm that. I'm running andy-tracking and when I call hexdump
 the first three entries are always axes 0, 1, 2.

-- 
:M:


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


SHR-U Accelerometer data

2009-12-17 Thread Iain B. Findleton
Many tests appear to indicate that a complete report set read from
/dev/input/event2 or event3 is a relative rarity. Looking at the code
from the lis302dl driver in git.openmoko.org it appears to me that this
should not be true, and if I recall correctly, proper output was couming
out under OM2009.x at one point.

Anybody with any thoughts on this issue? According to what I read,
/dev/input/eventx interface should reliably handle every event and make
it available.

The other issue is that the first report from the driver following an
open on the device should be complete and contain the axis calibration
values. This appears to be not true in that the first report I get is
often incomplete in that not all axes are supplied.

I am presuming that the lis302dl driver in use on SHR-U is the same one
as in the git repo. If not, where is the source being used by SHR?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community