Exp_Cropped Driver [Fixed!]
So I'm using the Cropped Experimental Driver- I think it's fbcp-ili9341?- and so far, I am blown away at how much more clean the refresh rate is than default, and am loving it. I am also on the latest FPCM3 image as of right now [Freeplay_CM3_19061802].

A few long-winded questions/concerns:
1. I might be missing the target in this one, but it seems like any use of OMXPlayer blacks the screen out [audio still running, though- so not locked up]. Although I'm a bit inexperienced here, I have a few guesses as to maybe why.

Instances have been when trying to run a video splashscreen on boot- tried the stock RetroPie one included, and one of my own that works just fine when on the "Default" driver.

Another one is when in EmulationStation, and running video screensavers. Screen blacks out, and picture does not return until rebooted.

Lastly, when I have video previews in the game lists- the screen will freeze right at that pane, and same as above- restored when restarted.

I've found that when disabling OMX in ES, and then simply not running a video splash- all works fine.

Conclusion: OMX uses HW decoding. Is this a disagreement of sorts with ili934
1? When OMX is disabled, and using- if I remember right- VLC, which is SW-based, there are no conflicts. Just less pretty videos, and no video splash. And heat. Lots of heat. It's ramping up the CPU  pretty harsh, naturally. So OMX is the preferred route, ultimately.

2. The animation/refresh rate is REALLY smooth. However, it seems when you're at any point of a stand-still, like say, not moving at all in ES, or sitting still in a game for a second where animation isn't heavy, you go to move- again, in menu, or in game- and there's about 3 seconds of jittering before it goes back to smooth. Almost like it's buffering, for lack of better term.

Fixed! Thank you, Porcinus!

I do not have the device yet (should be there in a few days Smile), but as soon as I get it I'll be playing with fbcp. I will then, probably, be able to answer some of your interrogation. 

In the meantime, you should take the time to read fbcp repo readme located here (if this is the one you are using): https://github.com/juj/fbcp-ili9341/blob.../README.md, there's a lot of useful informations and may give you some answer.
Thank you for the repo referral- I've actually been looking at it since Saturday. Although I've looked it over heavily, I think there is still something I'm missing that hasn't clicked yet that addresses these issues.

For starters- I've tried removing as much from the config.txt that the repo's instructions wants you to do- still to no avail on either of these fronts.
For the OMXPlayer, I have no clue to be honest. We've never experimented with video splashes or videos in ES, so it's natural we wouldn't encounter those issues. I do thing your assumption is correct, but the best person to ask would be the author, juj.

As for the stutter, we are aware and haven't looked into it much, if at all. I will take a look at it when I'm back from my short vacation, but doubt we'll be able to get a real solution since juj doesn't update the software much anymore.My shot in the dark would be that after it sees no changes in the screen for a certain amount of time, it turns on a lower refresh rate, and it takes a little bit to "catch up" when you start moving again. Good for battery and CPU savings, but not for menus. Thankfully, I can't think of many games offhand that keep a perfectly static screen for long enough to create stutter.
What's interesting is that when you set everything to use OMX- such as enabling a video splash, using OMX for screensaver videos, and videos on game list- it kills the output on the LCD, but everything over HDMI-out continues fully functional.

I have it hooked up via HDMI-out right now, and OMX is playing the video splash, game list videos, and video screensavers just fine.

Man- could it be as simple as something to do with how the HDMI output is duplicated to the LCD? I wonder if a certain HDMI setting will ultimately remedy this.
The fact that HDMI-out goes on to work normal, but the LCD is halted, and the nature of OMX is HW-based decoding, it all just seems to be working in tandem incorrectly.

The biggest problem here is that I know SO little about how all of this works, lol.
I'm literally just connecting really vague dots, and over all could be completely wrong.

What would be the best way to get in touch with juj?
Ultimately, though- like I said, I can live without OMX playback with the Exp_Cropped driver running. The smoothness is just a night and day difference, and seriously makes a better experience on these things, for sure. If only the buffering ended up solved, I wouldn't be sad at all.

I'll continue to poke around with this and share anything that might be useful.
(07-02-2019, 02:05 PM)Slow Catalyst Wrote: Ultimately, though- like I said, I can live without OMX playback with the Exp_Cropped driver running. The smoothness is just a night and day difference, and seriously makes a better experience on these things, for sure. If only the buffering ended up solved, I wouldn't be sad at all.

I'll continue to poke around with this and share anything that might be useful.

Yep, please do so Smile Knowing what you've done/found so far will help when the device arrive. 

Else, i do also think OMX support is not a priority (if a priority at all, at least for me). On a side note, there's no clean way to get the full display fit? I guess scaling does lower framerate again here.

Also, you may take a look at this commit : https://github.com/juj/fbcp-ili9341/comm...0a79f85925 and at SAVE_BATTERY_BY_SLEEPING_WHEN_IDLE define.
I see that you and juj are in talks- awesome!

SAVE_BATTERY_BY_SLEEPING_WHEN_IDLE definitely seems to describe what's going on. And it doesn't seem to "wake" or come out of idle until you really begin cycling the pixels heavily.

For example- when in EmulationStation, I have Carousel Selection on, and when sitting still for a few moments, then moving through the systems very fast, you can see it kind of "wake" back up. Just one way to describe the behavior.

It's true that it happens far less when in-game. But it definitely occurs when starting a game up as the driver has gone back to idle from the point of game selection to emulator loading it's BIOS. Another example- starting up GameBoy Color and using the BIOS file, and the color GAMEBOY text jitters right until the very last second, where again, you can see the driver kind of "waking" back up from idle.

This ultimately seems the most apparent when in menu, and using things such as carouseled selection, and starting up a game.

I'm not sure if it deals with something like a polling rate with the LCD and driver talking to each other, but man- this is literally the only thing that seems to be missing from making this driver functionally perfect in this application and setup. I can't seem to find any other visual issues besides this.
On a side note: I wonder how much more the use of this driver drains the battery as opposed to the Default driver.

I'm tempted to test this with certain battery-charge, brightness, and usage variables simultaneously, as I currently have a client build CM3 running Default, and my own CM3 build is of course running the Exp_Cropped driver right now to run against each other while timed.

Forum Jump:

Users browsing this thread: 1 Guest(s)