Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

Am 09.06.23 um 09:29 schrieb Geert Uytterhoeven:
Hi Thomas,

On Fri, Jun 9, 2023 at 9:09 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
Am 08.06.23 um 01:07 schrieb Javier Martinez Canillas:
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> writes:
On Wed, Jun 7, 2023 at 5:15 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
Am 07.06.23 um 10:48 schrieb Geert Uytterhoeven:
On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -57,6 +57,15 @@ config FIRMWARE_EDID
             combination with certain motherboards and monitors are known to
             suffer from this problem.

+config FB_DEVICE
+        bool "Provide legacy /dev/fb* device"

Perhaps "default y if !DRM", although that does not help for a
mixed drm/fbdev kernel build?

We could simply set it to "default y".  But OTOH is it worth making it a
default? Distributions will set it to the value they need/want. The very
few people that build their own kernels to get certain fbdev drivers
will certainly be able to enable the option by hand as well.

Defaulting to "n" (the default) means causing regressions when these
few people use an existing defconfig.


Having "dfault y if !DRM" makes sense to me. I guess is a corner case but
at least it won't silently be disabled for users that only want fbdev as
Geert mentioned.

IMHO the rational behind such conditionals are mostly what "we make up
here in the discussion", but not something based on real-world feedback.
So I'd strongly prefer a clear n or y setting here.


I wouldn't call it a regression though, because AFAIK the Kconfig options
are not a stable API ?

IIRC in the past there have been concerns about changing Kconfig
defaults. If we go with "default n", we'd apparently do something similar.


Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
to be selected by both FB and DRM_FBDEV_EMULATION?
Then FB_DEVICE can depend on FB_CORE, and default to y if FB.

Funny that you mention because it's exactly what I attempted in the past:

https://lore.kernel.org/all/20210827100531.1578604-1-javierm@xxxxxxxxxx/T/#u


That wouldn't work. In Tumbleweed, we still have efifb and vesafb
enabled under certain conditions; merely for the kernel console. We'd
have to enable CONFIG_FB, which would bring back the device.

"Default y" does not mean that you cannot disable FB_DEVICE, so
you are not forced to bring back the device?

I think we can have both to make the kernel more configurable:

1) Allow to only disable fbdev user-space APIs (/dev/fb?, /proc/fb, etc),
     which is what the series is doing with the new FB_DEVICE config symbol.

2) Allow to disable all "native" fbdev drivers and only keep the DRM fbdev
     emulation layer. That's what my series attempted to do with the FB_CORE
     Kconfig symbol.

I believe that there are use cases for both, for example as Thomas' said
many distros are disabling all the fbdev drivers and their user-space only
requires DRM/KMS, so makes sense to not expose any fbdev uAPI at all.

But may be that other users want the opposite, they have an old user-space
that requires fbdev, but is running on newer hardware that only have a DRM
driver. So they will want DRM fbdev emulation but none fbdev driver at all.

That's why I think that FB_DEVICE and FB_CORE are complementary and we can
support any combination of the two, if you agree there are uses for either.

I still don't understand the value of such an extra compile-time option?
   Either you have fbdev userspace, then you want the device; or you
don't then it's better to disable it entirely. I don't see much of a
difference between DRM and fbdev drivers here.

If you have DRM and are running a Linux desktop, you are probably
using DRM userspace.
If you have fbdev, and are using graphics, you have no choice but
using an fbdev userspace.

So with FB_CORE, you can have default y if you have a real fbdev driver,
and default n if you have only DRM drivers.

I'd also question the argument that there's even fbdev userspace out
there. It was never popular in it's heyday and definitely hasn't
improved since then. Even the 3 people who still ask for fbdev support

There's X.org, DirectFB, SDL, ...

None of these examples has a dependency on fbdev. They can freely switch backends and have moved to DRM. Anything program utilizing these examples has no dependency on fbdev either.

When I say "userspace" in this context, it's the one old program that supports nothing but fbdev. TBH I'm having problems to come up with examples.


What do you think low-end embedded devices with an out-of-tree[*]
fbdev driver are using?

And those do not count either. IIRC Android used to be built on top of fbdev devices. I'm not sure if they have moved to DRM by now. But embedded uses dedicated kernels and kernel configs. It's easy for them to set FB_DEVICE=y. We're not going to take away the fbdev device entirely.


[*] There's been a moratorium on new fbdev drivers for about a decade.

here only seem to care about the performance of the framebuffer console,
but never about userspace.

Unless you go for heavy graphics and 3D, a simple GUI with some
buttons and text requires less performance than scrolling a full-screen
graphical text console...

So I'd like to propose a different solution: on top of the current
patchset, let's make an fbdev module option that enables the device. If
CONFIG_FB_DEVICE has been enabled, the option would switch the
functionality on and off. A Kconfig option would set the default.  With
such a setup, distributions can disable the fbdev device by default.
And the few users with the odd system that has fbdev userspace can still
enable the fbdev device at boot time.

Hmm... That makes it even more complicated...

No, that makes things a lot easier for distros. Everyone else (custom builds, embedded) is not affected by this change. Desktop distros are really the only affected party I see here. "We" (I'm at Suse) have to support all kinds of users with just a few generic offerings. And if I can disable the fbdev device by default and give the very few fbdev users a workaround, it's a very good tradeoff.

Best regards
Thomas


Gr{oetje,eeting}s,

                         Geert


--
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)

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux