Framerate sometimes drops after a period of no controller input

[kmacmart@darkcloud.ca]

Hey all, I have plans to do some debugging but thought it might be worth seeing if anyone else had run into this over here first.

I've experienced this on both the default snes and gba emulators so it seems to be something at the system level. Everything runs silky smooth during gameplay, but if I stop pressing buttons for a number of seconds (eg: to respond to a text, watch a cutscene, etc) somewhere around 10% of the time I'll experience a considerable drop in framerate (down to maybe ~5-10fps) that will last until about 2 seconds after I start pressing buttons again.

My gut says there's some kind of input polling event that runs wild, but I've been traveling and haven't had the wifi adapter to ssh in and see what's up.

I'm running Freeplay_CM3_19061701.img.gz on a 2019 cm3.

Thanks!

[Porcinus]

Are you running experimental driver?
Your problem is similar to the one Slow Catalyst did encounter : https://forum.freeplaytech.com/showthread.php?tid=4931 in your case, the problem could be DISPLAY_CONSIDERED_INACTIVE_PERCENTAGE, it is hardcoded to 5% in https://github.com/juj/fbcp-ili9341/blob...r/config.h
Conbined to SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES, it could be the problem.

I am not English and I have some troubles understanding : 'My gut says there's some kind of input polling event that runs wild' :S

When you will have access to WiFi, you can try these commands :
'sudo jstest /dev/input/js0' , this only monitor joystick event.
'sudo evtest /dev/input/event0' , this one monitor all events, SYN included.

The GPIO driver has been update 20 days ago, this new version does handle analog input a different way to solve possible troubles with evdev input based emulator but I don't think your problem is related to this.

[Flavor]

Mootikins (https://forum.freeplaytech.com/member.ph...e&uid=5817) has done some testing with this recently. I will ask him to post here about his findings.

[Mootikins]

Hi kcmac, what specific games are you experiencing this with? Since it sounds like you haven't changed off of the default display driver, I assume you are using the juj driver.

My current theory is similar to Porcinus's, in that certain game cutscenes change so little of the screen that the driver considers these frames "static", and reduces the framerate to save battery. I don't think this is related at all to actual button inputs, since the display driver and button module are completely separated from each other, with the button module actually being a kernel level implementation to reduce latency and issues.

I would recommend (if you have the patience and skill) to try modifying and building a copy of the driver without these battery saving tweaks to see if that solves the issue. It should also be noted that any binaries built after commit edcdad will white screen when started as part of our Systemd modules, so you may need to git checkout edcdad to get to that commit before building.

UPDATE: As of today (July 19 2019) you do not have to checkout to commit edcdad; the issue has been resolved and you can use the commit that was made earlier today.

[kmacmart@darkcloud.ca]

Hey all, thanks for the replies! I'm actually using the experimental "Filled" driver but didn't think to mention it as I wasn't assuming the LCD driver would be responsible. I've experienced this with the only two games I've played so far: secret of mana and castlevania aria of sorrow, and it does typically seem to be when nothing is moving on screen when the issue is triggered now that it's been pointed out (that probably accounts for it only happening "~10%" of the time).

I'll see if I can build the display driver with the battery saving tweak patched out on a pi3 build bot I have running and will report back if I'm successful.

Thanks again!

[Porcinus]

I don't know if this will help : https://forum.freeplaytech.com/showthread.php?tid=4989

[Mootikins]

In addition to Porcinus' guide, I have also added two CM3 binaries to the repo that have the sleep turned off. If you wish to use them, connect your CM3 to the internet, pull the most recent version of the repo, stop your service with `sudo systemctl stop fbcp<version>`, and replace the binary with the NoSleep version. This way you don't have to compile it yourself.

[Slow Catalyst]

Mootikins, is there a more comprehensive write up of how to plug that in to the standard FreePlay image as you mention? I seem to be striking out, lol

[Mootikins]

In order, after sshing in (meaning you should be connected to the internet):
cd Freeplay/FreeplayILI9341
git pull
ls (to see all the available files, there are now 4 CM3 binaries; fbcpCropped, fbcpFilled, fbcpCroppedNoSleep, fbcpFilledNoSleep)
sudo systemctl stop fbcp[Filled/Cropped]
sudo cp fbcp[Filled/Cropped]NoSleep /usr/local/bin/fbcp[Filled/Cropped]
sudo systemctl start fbcp[Filled/Cropped]

To switch back, just replace the binary in /usr/local/bin/ with the version that doesn't have NoSleep.

[krisyadao]

I'm noticing a similar behavior, though it seems to be system wide. If I let it sit with no button presses long enough (maybe 10 seconds or so) things will get choppy. Games and the main menu are affected. Things will remain choppy until a second or two after pressing a button, then things smoothen up again.

I'm using the stock SD image with the filled driver option for BoxyPixel.