On 10/30/24 09:33, Thomas Zimmermann wrote:
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]
Sounds good.
Maybe you should ask Mikulas if it helps him?
[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.
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.
Helge
