On 11/1/24 09:19, Thomas Zimmermann wrote:
Am 30.10.24 um 10:30 schrieb Helge Deller:
I'm happy to get rid of the fbdev drivers, but for that DRM really needs
to allow some sort of native fillrect, copyarea and imageblt operations so
that we can get performance back on the old cards when implementing them
as DRM driver.
This is unrelated to udl.
No, it's not.
The udl fbdev driver implements those functions (like the other fbdev drivers)
and as such fbcon on top of udl is accelerated, while fbcon on drm drivers
is unaccelerated.
Udlfb uses the regular software implementations to draw into its
shadow buffer. It then schedules an update to copy the update over
USB to the adapter's internal framebuffer memory. [1] Udl uses
exactly the same code pattern and most of the involved helpers. [2]> [1] https://elixir.bootlin.com/linux/v6.11.5/source/drivers/video/fbdev/udlfb.c#L1145
[2] https://elixir.bootlin.com/linux/v6.11.5/source/drivers/gpu/drm/drm_fbdev_shmem.c#L39
Yes, you are correct with this summary for those drivers which use the damage helpers.
Maybe the previous udlfb driver had one additional optimization where it might bitblt the screen when scrolling, but this is just an assumption I did not check now.
I don't have that card, but if Mikulas can test and verify that the drm driver is now ok for him, I'm fine that we drop udlfb.
Please note that my statement above that DRM should support native fillrect, copyarea and imageblt operations is still true. Without those fbcon is too slow and flickering on old machines and fbdev cards.
Helge
