[Gta04-owner] Second trial with QtMoko2

[H. Nikolaus Schaller]

> Am 18.04.2018 um 14:31 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi all,
> 
>> Am 18.04.2018 um 08:20 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi Sebastian,
>> 
>>> Am 17.04.2018 um 21:45 schrieb Sebastian Krzyszkowiak <dos at dosowisko.net>:
>>> 
>>> On Tue, Apr 17, 2018 at 9:09 PM, H. Nikolaus Schaller <hns at goldelico.com> wrote:
>>>> 
>>>> Am 17.04.2018 um 21:05 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>> 
>>>> Hi Sven,
>>>> 
>>>> Am 17.04.2018 um 16:31 schrieb Sven Dyroff <S.Dyroff at phytec.de>:
>>>> 
>>>> Hello Nikolaus,
>>>> 
>>>>> It looks as if it is much more often reporting accelerometer events (ca.
>>>>> 15ms) than the 4.16 kernel (ca. 100-200ms).
>>>> 
>>>>> But neither change has the effect of making the graphics faster and
>>>>> smoother.
>>>> 
>>>>> So there is likely a third factor involved when comparing to GTA02.
>>>> 
>>>> no, I think you've found the cause!
>>>> 
>>>> 100-200ms results in a frame rate of 5 to 10 Hz which is awfully slow!
>>>> 
>>>> 
>>>> Unfortunately no. Would be too simple...
>>>> 
>>>> There is a background thread that reads the accelerometer every now and then
>>>> and
>>>> simply returns the last value each time it is called. So these speeds are
>>>> completely
>>>> decoupled! QtMaze does not see any delay in code when calling getacx(). This
>>>> returns the value of a global variable that is updated by the background
>>>> thread.
>>>> 
>>>> The accelerometer delay can only be recognized by a delayed reaction but
>>>> has no influence on the frame rate. So graphics should not have small jumps
>>>> if
>>>> you don't move the device...
>>>> 
>>>> So we still have to dig deeper into it... For example someone could look
>>>> into the sources of QtMaze how the display redrawing is done.
>>>> 
>>>> 
>>>> It is here:
>>>> 
>>>> http://git.goldelico.com/?p=gta04-qtmoko.git;a=tree;f=src/3rdparty/games/qtmaze;h=38f4df583bba2a4712baf40915bc0026fb16dc8d;hb=398d5c957571fed6b63174cfd2e4b6d57aeff9a4
>>> 
>>> From a quick glance at the code (form.cpp) is looks like the ball is
>>> moved only in the MoveBall method, which is called only in the
>>> callback from accelerometer thread (and in some other function too,
>>> but that function is also called only from that same callback).
>>> In the library, accel_work (the accelerometer thread) calls
>>> accelerometer_moo in a while loop until it gets a measurement and only
>>> then calls the QtMaze's callback, which seems to be the only way to
>>> actually update the ball's position.
>>> 
>>> It shouldn't really work that way, and I there's a possibility that
>>> I'm mistaken since I just had a few minutes look into a codebase I
>>> never seen before, but it does really seem that by lowering the
>>> accelerometer read rate you'll get lowered ball movement frame rate in
>>> QtMaze :)
>> 
>> Thanks for looking into this!
>> 
>> Well, if your analysis is right, then QtMaze was developed on the
>> false assumption that accelerometer callbacks come in fast and well
>> clocked steps.
>> 
>> But the kernel and the accelerometers.cpp try their best to filter
>> out unneeded callbacks...
>> 
>> Well, I have a simple idea for a fix: remove the dependency of calling the
>> callback from really having received new data from the kernel.
>> 
>> I.e.:
>> 
>> 	while ( !(my_thread_data->finished) ) {
>> 
>> 		/* Call accelerometer_moo() until we have an
>> 		   acceleration measurement. */
>> 		accelerometer_moo(accel);
>> 
>> 		/* If the library user specified a callback, call
>> 		   it. */
>> 		if (my_thread_data->callback)
>> 		  (*my_thread_data->callback)(my_thread_data->closure,
>> 					      acx, acy, acz);
>> 		/* Sleep before taking another measurement. */
>>               usleep(my_thread_data->interval_us);
>>       }
>> 
>> So we do not call accelerometer_moo() until we have a measurement
>> but we call it once every interval_us. And do the callback once.
>> 
>> This should then become the timer triggering a redraw and should
>> be almost equidistant.
>> 
>> It is then the same as for the GTA02 code which calls the callback once
>> per loop...
> 
> Ok, this works. The ball is now moving fast like hell...
> IMHO too fast, but it now looks like with the GTA02 video.
> 
> Same on the Pyra, but there, ball movements get completely stuck
> after some seconds. evtest /dev/input/accel still reports events
> and QtMaze still is responsive to the touchscreen, but no longer to the
> accelerometer. So this is some other bug...
> 
> I'll now push the update to the server. Please try an apt-get upgrade in
> some hours (should load & install qtmoko-gta04_60.20180418-1_armhf.deb ).

And here is a new video:

https://youtu.be/DSbuXz_EZTo