drm/ast something ate high-res modes (5.3->5.6 regression)

Thomas Zimmermann tzimmermann at suse.de
Wed Oct 14 07:09:13 UTC 2020


Hi

On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen"
<ilpo.jarvinen at cs.helsinki.fi> wrote:

> On Thu, 17 Sep 2020, Thomas Zimmermann wrote:
> 
> > Hi
> > 
> > Am 17.09.20 um 13:17 schrieb Ilpo Järvinen:
> > > Hi,
> > > 
> > > Yes, I can build custom kernels and test but I won't have time for that 
> > > before the end of September so I'll do it only then.
> > 
> > No problem, that's still fine.
> > 
> > Best regards
> > Thomas
> > 
> > > 
> > > And thanks a lot :-).
> > > 
> 
> The high-res mode works, however, I wasn't expecting it to be this slow 
> though as I can see the slowish sweeps to redraw the screen or large parts 
> of it. Maybe you meant all along this slow (I was expecting something like 
> memcpy slow and this looks definitely much slower)?

First of all, thanks for testing. I didn't expect it to be that slow either.

> 
> While a large redrawing operation is going on, mouse cursor stops moving 
> normally until it is over and it then jumps to catch up. When the mouse is 
> over something that doesn't require large redraw, it seems to work quite 
> normally.
> 

That sounds bad. The cursor is drawn by hardware, so I'd expect it to move
smoothly across the screen. Maybe the position update is blocked from the
framebuffer's memcpy within the kernel code.

I was hoping the performance would be acceptable, but this sounds like a
dealbreaker to me. I can look a bit closer if there are issues/bugs in the
code that make it run slow. Not holding my breath for it though...

Best regards
Thomas


More information about the dri-devel mailing list