[PATCH] fbdev: udl: Make CONFIG_FB_DEVICE optional

[Thomas Zimmermann]

Hi

Am 29.10.24 um 21:42 schrieb Helge Deller:
> Hi Thomas,
>
> On 10/28/24 09:41, Thomas Zimmermann wrote:
>> Am 25.10.24 um 17:37 schrieb Helge Deller:
>>> On 10/25/24 11:25, Gonzalo Silvalde Blanco wrote:
>>>> The fb_udl driver currently depends on CONFIG_FB_DEVICE to create 
>>>> sysfs
>>>> entries and access framebuffer device information. This patch wraps 
>>>> the
>>>> relevant code blocks with #ifdef CONFIG_FB_DEVICE, allowing the 
>>>> driver to
>>>> be built and used even if CONFIG_FB_DEVICE is not selected.
>>>>
>>>> The sysfs setting only controls access to certain framebuffer 
>>>> attributes
>>>> and is not required for the basic display functionality to work 
>>>> correctly.
>>>> (For information on DisplayLink devices and their Linux support, see:
>>>> https://wiki.archlinux.org/title/DisplayLink).
>>>>
>>>> Tested by building with and without CONFIG_FB_DEVICE, both of which
>>>> compiled and ran without issues.
>>>
>>> Gonzalo, I don't like this patch very much.
>>>
>>> It adds lots of #ifdefs around functions like dev_dbg().
>>> Instead of ifdefs, aren't there other possibilities, e.g.
>>> using fb_dbg() if appropriate?
>>> Or using any other generic dbg() info or simply dropping the line?
>>
>> I talked Gonzalo into sending this patch. I think dev_dbg() calls
>> should be replaced with fb_dbg(), same for _info() and _err(). That's
>> probably worth doing anyway.
>
> Yes, but I doubt every of those calls can be replaced...
>
>>> But more important:
>>> This is a fbdev driver and currently depends on CONFIG_FB_DEVICE.
>>> If I'm right, the only reason to disable CONFIG_FB_DEVICE is if
>>> you want fbdev output at bootup, but otherwise just want to use DRM.
>>
>> It's unrelated to booting. CONFIG_FB_DEVICE enables/disables
>> userspace interfaces (/dev/fb*, /sys/graphics/fb*). Even without,
>> there's still fbcon that runs on top of the fbdev driver.
>
> Sure, I meant that if people enable a fdev driver, they most likely
> want /dev/fb as well ..... unless they want to use mostly DRM drivers.
>
>>> But then, doesn't there exist a native DRM driver for this graphics
>>> card which can be used instead?
>>> If so, I suggest to not change this fbdev driver at all.
>>
>> Or can we talk about removing udlfb entirely? I tried before, but
>> there was one person still using it. [1] He had concerns about udl's
>> (the DRM driver) stability. I think DRM's udl has matured enough and
>> is in better shape than udlfb. Maybe we can try again.> [1] 
>> https://lore.kernel.org/dri-devel/20201130125200.10416-1-tzimmermann@suse.de/
>
> The stability was one of the issues, but IMHO the *main* issue he 
> mentions is this:
>
> The framebuffer driver is faster, it keeps back buffer and updates only
> data that differ between the front and back buffer. The DRM driver 
> doesn't
> have such optimization, it will update everything in a given rectangle -
> this increases USB traffic and makes video playback more jerky.

If that was a problem, it has long been solved. [1][2] The DRM udl 
driver keeps a backbuffer in system memory. The DRM API provides 
built-in damage handling, so that clients can mark the framebuffer 
regions that have been written. Udl will only update the regions that 
have been modified.

For fbdev support specifically, the fbdev code mmaps the drivers 
internal backbuffer to userspace and does deferred I/O and damage 
handling on these pages. Hence, there's only one transfer over USB with 
no internal copying. There used to be more internal copying, but that is 
gone. [3]

[1] https://patchwork.freedesktop.org/patch/501943/
[2] https://patchwork.freedesktop.org/patch/506133/
[3] https://patchwork.freedesktop.org/patch/590306/?series=131037&rev=4

>
> That's exactly the main concern I'm regularily bringing up and which
> IMHO is the main reason we still have many fbdev drivers.
> You added support for some of those graphics cards with native DRM
> drivers, but all of them are unaccelerated. This hurts a lot on old
> machines and as such specific cards are ugly slowly with DRM.
> A good example for this is the kvm drm graphics driver which is sluggish
> and slow when using KVM.
>
> 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.

Best regards
Thomas

>
> Helge

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)