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

["Ilpo Järvinen" <ilpo.jarvinen@cs.helsinki.fi>]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Wed, 8 Jul 2020, Thomas Zimmermann wrote:

> Hi
> 
> Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
> > Hi,
> > 
> > After upgrading kernel from 5.3 series to 5.6.16 something seems to 
> > prevent me from achieving high resolutions with the ast driver.
> 
> Thanks for reporting. It's not a bug, but a side effect of atomic
> modesetting.
> 
> During pageflips, the old code used to kick out the currently displayed
> framebuffer and then load in the new one. If that failed, the display
> went garbage.
> 
> In v5.6-rc1, we merged atomic modesetting for ast. This means that
> screen updates are more reliable, but we have to over-commit resources.
> Specifically, we have to reserve space for two buffers in video memory
> while a pageflip happens. 1920x1200@32 are ~9MiB of framebuffer memory.
> If your device has 16 MiB of VRAM, there's no space left for the second
> framebuffer. Hence, the resolution is no longer supported.
> 
> On the positive side, you can now use Wayland compositors with ast.
> Atomic modesetting adds the necessary interfaces.

Ok, thanks for the info although it's quite disappointing (not the first 
time to lose features with kms, migrating to it made me to lose dpms) ;-).

As it's quite annoying to lose a high resolution mode (or be stuck in 
some old kernel), would it be technically feasible to make the framebuffer 
allocation asymmetrical? That is, the switch to high-res mode would get
rejected when it would be into the smaller of the two buffers but not when 
the arrangement is the other way around?


-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel