Openmoko Bug #2366: Missing accelerometer events

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Openmoko Bug #2366: Missing accelerometer events

Openmoko Public Trac
#2366: Missing accelerometer events
---------------------+------------------------------------------------------
 Reporter:  mkburza  |          Owner:  openmoko-kernel    
     Type:  defect   |         Status:  new                
 Priority:  highest  |      Milestone:  stable-kernel-2009.1
Component:  kernel   |        Version:  unspecified        
 Severity:  normal   |       Keywords:                      
 Haspatch:  0        |      Blockedby:                      
Estimated:           |    Patchreview:                      
 Blocking:           |   Reproducible:                      
---------------------+------------------------------------------------------
 I am using following version of the software:
 http://build.shr-project.org/shr-unstable/images/om-gta02/shr-full-eglibc-
 ipk--20100828-om-gta02.rootfs.jffs2
 http://build.shr-project.org/shr-unstable/images/om-
 gta02/uImage-2.6.32.21-oe3.3+gitr6+a9254be10ac2294ea20165a87c09ea6afcf66d94-r0
 -om-gta02.bin

 I read accelerometer events with following C program:

 #include <stdio.h>
 #include <sys/select.h>
 #include <sys/time.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/ioctl.h>
 #include <fcntl.h>
 #include <unistd.h>
 #include <stdlib.h>
 #include <time.h>
 #include <linux/input.h>
 #include <signal.h>
 #include <string.h>
 #include <errno.h>
 #include <assert.h>
 #include <sys/times.h>

 int read_all(int fd, char *buffer, int count){

     int got = 0;
     while(got != count) {

         int result = read(fd, buffer + got, count - got);
         if(result > 0){

             got += result;

         }

     }
     return got;

 }

 int grab = 2;

 int main(int argc, char *argv[]){

     int fd, i;
     struct input_event ev[128];

     if((fd = open("/dev/input/event3", O_RDONLY)) == -1){

         perror("Open");
         return 1;

     }
     int ioret = ioctl(fd, EVIOCGRAB, &grab); // Without this I also get
 missing events
     if(-1 == ioret){ // but I was hoping it would help

         perror("ioctl()"); //

     } //

     int got = read_all(fd, (char*)ev, 128 * sizeof(struct input_event));
     close(fd);
     for(i = 0; i < 128; i++){

         printf("type:%u code:%u value:%d\n", ev[i].type, ev[i].code,
 ev[i].value);

     }
     return 0;

 }

 As you can see I first collect all the events and then I print them out to
 avoid any waiting time which would result in missing events.
 In principle if everything is fine I would expect such pattern on the
 output:
 type:3 code:0 value:[whateverX]
 type:3 code:1 value:[whateverY]
 type:3 code:2 value:[whateverZ]
 type:0 code:0 value:0

 Here is a fragment of real output:
 type:3 code:0 value:-284
 type:3 code:1 value:355
 type:3 code:2 value:497
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:3 code:1 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:2 value:994
 type:0 code:0 value:0
 type:3 code:2 value:923
 type:0 code:0 value:0
 type:3 code:0 value:0
 type:0 code:0 value:0
 type:3 code:0 value:71
 type:0 code:0 value:0

 As you can see the pattern of having three consecutive events reporting
 each of the axis followed by sync event is broken and often events for
 some x, y or z are missing.

 I checked how the program behaves if I collect the events for several
 minutes (it is the same with randomly missing events). I tried to increase
 the priority with nice to see if that helps (thinking that maybe the
 processor is too busy) - it didn't help. I checked the CPU usage - it does
 not go over 20% overall (15% for the process which reads the events).

 Here is the configuration of the accelerometer:
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/sample_rate:
 100
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/full_scale:
 9.2
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/threshold:
 0
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/duration:
 0
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/dump:
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b
 a8 95 01 13 13 01 06 82 01 e3 0e 58 00 00 00 00
 20 00 a4 00 00 00 00 00 00 01 00 00 00 0d 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/wakeup_threshold:
 off
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/wakeup_duration:
 0
 /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/spi_s3c24xx_gpio.0/spi3.0/overruns:
 1

 This was checked on several Freerunners and all of them behave the same.
 Please let me know if you need further data/config info/etc.

 Best regards,
 Mark

 PS: I reported this at first on SHR's trac but after they looked into it
 they asked me to post it here as it concerns the kernel.

--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2366>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Openmoko Bug #2366: Missing accelerometer events

Openmoko Public Trac
#2366: Missing accelerometer events
---------------------+------------------------------------------------------
 Reporter:  mkburza  |          Owner:  openmoko-kernel    
     Type:  defect   |         Status:  new                
 Priority:  highest  |      Milestone:  stable-kernel-2009.1
Component:  kernel   |        Version:  unspecified        
 Severity:  normal   |       Keywords:                      
 Haspatch:  0        |      Blockedby:                      
Estimated:           |    Patchreview:                      
 Blocking:           |   Reproducible:                      
---------------------+------------------------------------------------------

Comment(by neilbrown):

 This is expected behaviour.
 These are events that report when something changes.
 If nothing changes, you don't get an event.

 In particular, if the X and Y acceleration changes but the Z acceleration
 doesn't, you get
 X and Y events but not Z events.  You need to think of then as 3 separate
 accelerometers which report separately.

 If you want to find the current value of any of the three, you can either
 remember the last time it reported, or use the EVIOCGABS ioctl (See
 /usr/include/linux/input.h for details)

--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2366#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Openmoko Bug #2366: Missing accelerometer events

Openmoko Public Trac
In reply to this post by Openmoko Public Trac
#2366: Missing accelerometer events
---------------------+------------------------------------------------------
 Reporter:  mkburza  |          Owner:  openmoko-kernel    
     Type:  defect   |         Status:  new                
 Priority:  highest  |      Milestone:  stable-kernel-2009.1
Component:  kernel   |        Version:  unspecified        
 Severity:  normal   |       Keywords:                      
 Haspatch:  0        |      Blockedby:                      
Estimated:           |    Patchreview:                      
 Blocking:           |   Reproducible:                      
---------------------+------------------------------------------------------

Comment(by mkburza):

 Thanks for such a quick reply!!!

 > This is expected behaviour.
 > These are events that report when something changes.

 I see, if that is the expected behavior then that's something I can live
 with. And thanks for the suggestion about the EVIOCGABS - I might use that
 one!

 One more question though before I let go of that matter - I do observe
 that when the phone lies flat on a table X is updated the least, Y about
 twice as often and Z at least three times as often as X.
 Even if I would assume that the measurement gets noisier due to the
 gravity force acting along the Z axis (which I do not know if I can
 assume) this still does not explain why is Y updated more frequently than
 X (and it is a behavior I consistently observe on multiple Freerunners).
 Do you have any (possible) explanation for that?

--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2366#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Openmoko Bug #2366: Missing accelerometer events

Openmoko Public Trac
In reply to this post by Openmoko Public Trac
#2366: Missing accelerometer events
---------------------+------------------------------------------------------
 Reporter:  mkburza  |          Owner:  openmoko-kernel    
     Type:  defect   |         Status:  new                
 Priority:  highest  |      Milestone:  stable-kernel-2009.1
Component:  kernel   |        Version:  unspecified        
 Severity:  normal   |       Keywords:                      
 Haspatch:  0        |      Blockedby:                      
Estimated:           |    Patchreview:                      
 Blocking:           |   Reproducible:                      
---------------------+------------------------------------------------------

Comment(by neilbrown):

 No, I cannot explain that.

 Every time the accelerometers report a sample - which is 100 times per
 second I think - those
 samples are passed to the 'input' layer in Linux.  This input layer
 removes the duplicates.

 So it might be somehow related to noise, whether physical or electrical.
 I have no idea why
 X is most noisy and Z is least noisy.

--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2366#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
Loading...