On Wed, Feb 26, 2020 at 04:54:35PM +0100, Lucas Stach wrote:
On Mi, 2020-02-26 at 15:31 +0000, Schrempf Frieder wrote:
On 25.02.20 09:13, Frieder Schrempf wrote:
Hi Lucas,
On 24.02.20 12:08, Lucas Stach wrote:
On Mo, 2020-02-24 at 10:53 +0000, Schrempf Frieder wrote:
Hi Lucas,
On 24.02.20 11:37, Lucas Stach wrote:
Hi Frieder,
On Mo, 2020-02-24 at 10:28 +0000, Schrempf Frieder wrote: > On 20.02.20 19:58, Chris Healy wrote: > > For the jerkey transitions, can you determine if this is a symptom of > > a low framerate or dropped frames or something else? > > > > Perhaps you can start your app with > > "GALLIUM_HUD=fps,cpu,draw-calls,frametime". This may give some > > clues. > > The framerate seems ok. I get something between 50 and 70 FPS. > > I have a Qt demo app with a menu and an animated 'ball' that moves > across the screen. When the menu is visible, the ball movement is > really > jerky (ball seems to 'jump back and forth' instead of moving > linearly). > > As soon as I hide the menu and show the animation fullscreen, the > movements are perfectly smooth. > > Running the same app with software rendering, everything looks > good, too. > > No idea what that means, though. I probably need to look at the > code of > the app and do some more experiments to get a better idea of what > might > cause the distortion. > > Unless some of the graphics experts here already have an idea of what > can cause and/or how to debug such an issue!?
Which driver is used for the display side? It seems like the display side doesn't properly handle the dma fences used to synchronize scanout and rendering.
I ported/picked the drivers for the LCDIF and DSI controllers from development branch of the 5.4-based vendor kernel [1] to our own v5.4-based kernel [2]. So it is quite probable, that something could be wrong here.
Please just use DRM_MXSFB for the display side, instead of the downstream driver.
Hm, good idea. I somehow forgot about the fact, that there is an upstream driver for the LCDIF controller. On first try I couldn't get it to run on the i.MX8MM, but I suspect that's due to some reset, power-domain or clock setup, that is missing upstream. I will see if I can get any further with this.
So I had a closer look and while the DRM_MXSFB looks ok on its own, I have some problem with the rest of the i.MX8MM display subsystem.
The vendor stack, that I'm currently using integrates into the imx-drm master/core driver [1] that binds all the components of the display subsystem, such as the LCDIF driver and the integrated SEC_DSIM DSI bridge.
And because of my lack of DRM skills, I have no idea how to get the DRM_MXSFB driver to bind to the imx-drm core, instead of running separately and connecting directly to some panel as it is done for i.MX23/28 and i.MX6SX/UL.
It's a separate hardware and it's a pretty major design issue of the downstream driver that it integrates into imx-drm. You don't want this with the upstream driver.
Maybe Guido (CCed) can give you some clues, as apparently he is using the mainline eLCDIF driver + some patches to drive the DSI display path on i.MX8MQ. A lot of this will probably be transferable to the i.MX8MM display path.
Newer mxsfb supports attaching a bridge so if you make your DSI host controller driver a DSI bridge mxsfb can drive it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
this should be similar to what was done for the imx8mq here (imx8mm users a different ip core though):
https://source.puri.sm/guido.gunther/linux-imx8/commits/forward-upstream/nex...
There's also some additional mxsfb patches by Robert floating around which aren't mainline yet which the above branch also has.
Which reminds me that i need to prepare and send out a v9. Cheers, -- Guido