[PATCH] fbdev: udl: Make CONFIG_FB_DEVICE optional

Helge Deller deller at gmx.de
Sat Nov 2 14:08:15 UTC 2024


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


More information about the dri-devel mailing list