On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@xxxxxx> wrote: > > On 1/17/22 17:21, Helge Deller wrote: > > On 1/17/22 16:58, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 17.01.22 um 16:42 schrieb Helge Deller: > >>> [...] > >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, > >>>>> either when run on native hardware or in an emulator. > >>>>> d) not break DRM development > >>>>> > >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to > >>>>> understand where the actual problems were and what's necessary to fix them. > >>>>> > >>>>> Helge > >>>>> > >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@xxxxxx > >> > >> Seems like few people read linux-fbdev these days. > >> I suggest to partly revert the patch to the point were performance > >> gets better again. > > Yes, *please*! > > That would solve my biggest concern. > > > > As far as I can see that's only 2 commits to be reverted: > > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" > > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next > > > > I think both were not related to any 0-day bug reports (but again, I might be wrong). > > I did some more checking... > > Both patches are not related to DRM, since no DRM driver sets the > FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags. These used to be set by, at least, nouveau (which is a drm driver). And yeah, console responsiveness is _way_ worse without that. People keep pushing the messaging that it's the same speed to do it as memcpy, but that's just not the case in my experience, on a pretty bog-standard x86 desktop. The support got dumped, and it felt pretty clear from the messaging at the time, "too bad". Would love to see it come back. Cheers, -ilia
