[Letux-kernel] evtest /dev/input/accel

H. Nikolaus Schaller hns at goldelico.com
Tue Apr 17 14:08:17 CEST 2018


Hi,
(cross-posted to gta04-owner since we have a first result)

> Am 17.04.2018 um 10:45 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> I now have extracted the QtMoko accelerometer handler code [1]
> into a simple command line utility.
> 
> <accel-test.c>
> 
> This basically works, except for the following observations:
> 
> 1. sometimes one axis is reported as "0" in between.
> 
> This comes because there may be SYN_REPORT (EV_SYN) on
> the first read after opening the device before all
> 3 axis are reported. This may be a race between opening
> the event device and the driver providing the first events.
> 
> This is harmless, because QtMoko or QtMaze opens the
> device only once and future events are collected while
> the accel-test program opens and closes the device for
> each call.
> 
> 2. accel-test does not have a background thread to
> collect events.
> 
> In QtMoko there is a background thread that tries
> every 12.5 ms to collect events. This seems to differ
> from GTA02 which has 2 ms.
> 
> So the GTA02 may sample more often, but that should
> not have an influence on the game speed. Because
> it runs in a background thread *and* the game defines
> the frame rate which likely defines the visual physics.
> 
> 3. it seems as if there is an active polling loop
> until data becomes available. This is
> 
> 325                 /* Call accelerometer_moo() until we have an
> 326                    acceleration measurement. */
> 327                 while (!accelerometer_moo(accel))
> 328                   ;
> 329 
> 
> This makes the background thread poll until a SYN_REPORT
> has been received where we can assume that all axis
> information is available.
> 
> For me this looks as if this is done at 100% CPU load
> because the select() call has a zero timeout.
> 
> This could of course slow down the main application,
> i.e. drawing of the graphics.
> 
> I am not sure, but I think this should either become
> a blocking select() call.
> 
> Or there should not be an inner while loop in the thread
> handler.
> 
> The Neo GTA02 code also does a non-blocking select() but
> then always makes the thread sleep for 2 ms.
> 
> So maybe accel_work() should look like:
> 
> 323       while ( !(my_thread_data->finished) ) {
> 324 
> 325                 /* Call accelerometer_moo() until we have an
> 326                    acceleration measurement. */
> 327                 if (accelerometer_moo(accel))
> 328                   {
> 329 
> 330                 /* If the library user specified a callback, call
> 331                    it. */
> 332                 if (my_thread_data->callback)
> 333                   (*my_thread_data->callback)(my_thread_data->closure,
> 334                                               acx, acy, acz);
> 335                   }
> 336                 /* Sleep before taking another measurement. */
> 337                 usleep(my_thread_data->interval_us);
> 338         }
> 
> Please comment while I'll test...

Ok, I have tested that piece of code.

- it works :)
- but I can't notice a difference in QtMaze graphics :(

Anyways, it is a big improvement!

With old version we had >80% CPU load by QtMaze sitting on the table:

top - 00:04:05 up 4 min,  2 users,  load average: 1.08, 0.93, 0.42
Tasks:  79 total,   1 running,  53 sleeping,   0 stopped,   0 zombie
%Cpu(s): 14.7 us, 72.1 sy,  0.0 ni, 13.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    500096 total,   246072 used,   254024 free,    11908 buffers
KiB Swap:        0 total,        0 used,        0 free,   147280 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                                                                                               
 3386 root      20   0 45220  24m  16m S  83.8  4.9   0:09.61 qtmaze                                                                                                                                                                                               
   17 root      20   0     0    0    0 I   1.0  0.0   0:01.11 kworker/0:1                                                                                                                                                                                           
  472 root     -51   0     0    0    0 S   0.7  0.0   0:00.40 irq/72-48070000                                                                                                                                                                                       
 3384 root      20   0  2712 1776 1336 R   0.7  0.4   0:00.28 top                                                                                                                                                                                                   

With new code we have just 3%:

top - 00:09:07 up 9 min,  2 users,  load average: 1.60, 1.55, 0.84
Tasks:  77 total,   1 running,  53 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.7 us,  1.7 sy,  0.0 ni, 96.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    500096 total,   273088 used,   227008 free,    12724 buffers
KiB Swap:        0 total,        0 used,        0 free,   172472 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                                                                                               
 3497 root      20   0 45220  24m  16m S   3.6  4.9   0:01.57 qtmaze                                                                                                                                                                                               
 3495 root      20   0  2712 1852 1412 R   1.3  0.4   0:00.55 top                                                                                                                                                                                                   
  951 root      20   0     0    0    0 I   1.0  0.0   0:00.27 kworker/0:2                                                                                                                                                                                           
  476 root     -51   0     0    0    0 S   0.3  0.0   0:00.53 irq/73-48072000                                                                                                                                                                                       
 3472 root      20   0  116m  52m  27m S   0.3 10.8   0:03.66 qpe                                                                                                                                                                                                   
    1 root      20   0  1696 1016  912 S   0.0  0.2   0:04.13 init                                                                                                                                                                                                 
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kthreadd                                                                                                                                                                                             

So QtMaze was quite a heavy Energy consumer because of this unnecessary
busy loop... And now the omap3 is clocked down to 300 MHz most of the time.

For the "stuttering" problem of QtMaze I suspect that the graphics backend
of Qt waits for vertical retrace to guard the frame rate. This ioctl might
different from new kernels with kernel 3.7... AFAIR the whole omap3 display
system has been replaced since that times.

Maybe, next I should try if I can boot our latest QtMoko2 with a 3.7 kernel :)
Just for comparison.

BR,
Nikolaus

> BR,
> Nikolaus
> 
> [1]: http://git.goldelico.com/?p=gta04-qtmoko.git;a=blob;f=src/libraries/accelerometer/accelerometers.cpp;h=4bd95bccf91d301512800b9fafdd7e4a610b1a70;hb=618ac5b867ba807e749213fde74fe9b0afe935c4
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel



More information about the Letux-kernel mailing list