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@xxxxxxx/
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)
