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 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: > > 1. dpms off > > 2. allocate big buffer > > 3. 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. -- i.