Hi

Am 08.07.20 um 16:22 schrieb Thomas Zimmermann:
> Hi
> 
> Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
>> 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'm not sure what you mean here, but generally, there's no way of fixing
> this without performance penalty.

I actually considered this, but didn't think it was worth it. The
high-res modes would be sluggish. But then again, they already were, so
it might not make much of a difference...

Best regards
Thomas

> 
> The screen resolution is only programmed once. Later updates only
> require pageflips. For each pageflip, atomic modesetting requires the
> new and the old framebuffer in video memory at the same time. These two
> framebuffers are typically allocated once by Gnome/KDE/etc compositors,
> and compositors go back and forth between them. It's basically double
> buffering.
> 
> Best regards
> Thomas
> 
>>
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer