On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
Am 08.07.20 um 16:26 schrieb Daniel Vetter:
On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann tzimmermann@suse.de wrote:
Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
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) ;-).
kms still has dpms, not sure what you mean here? Maybe some driver doesn't implement it.
Yes I know (it related only to in-kernel ast driver lacking it).
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.
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.
Ah, so there is a technical obstacle. I thought that those 2nd copies of buffers are only necessary during a switch from one resolution to another one.
You can do high-res mode I think, maybe needs a driver option to allow it to avoid upsetting existing compositors. Roughly:
- dpms off
- allocate big buffer
- dpms on in high res mode with that single buffer
Pageflip will fail ofc with ENOSPC, but kms itself doesn't disallow this. We could even implement this fairly generic, with a setcap flag, which makes the probe helpers _not_ filter out modes which wouldn't fit at least 2 framebuffers at the same time.
I cannot really understand full impact of this (what would not work).
Technically you can hack up something, but what's the benefit for the overall ecosystem?
In my other reply, I was rather talking about replacing VRAM helpers with SHMEM helpers. That would imply a memcpy from system into video memory on each pageflip.
OTOH, ast currently recommends using a shadow framebuffer, so userspace probably already does the memcpy somewhere. And now that SHMEM helpers can easily do cached page mappings, the performance difference might not be significant. Maybe I should give it a try.
I'd highly appreciate that (but I guess I might quite small minority when it comes to "ecosystems" :-)). And I wouldn't be too worried about performance penalty.