Re: [PATCH] fbdev: Have CONFIG_FB_NOTIFY be tristate

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

 



On 5/7/24 04:44, Arnd Bergmann wrote:
On Tue, May 7, 2024, at 13:10, Daniel Vetter wrote:
On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:
On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:
On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:
On 5/3/24 12:45, Arnd Bergmann wrote:

This is the current Android GKI config:
https://android.googlesource.com/kernel/common.git/+/refs/heads/android-mainline/arch/arm64/configs/gki_defconfig
where I can see that CONFIG_DRM is built-in, but DRM_FBDEV_EMULATION
CONFIG_VT, CONFIG_FRAMEBUFFER_CONSOLE, CONFIG_FB_DEVICE and
CONFIG_FB_CORE are all disabled.

So the console won't work at all,I think this means that there
is no way to get the console working, but building a fb.ko module
allows using /dev/fb with simplefb.ko (or any other one) happens
to almost work, but only by dumb luck rather than by design.

So using /dev/fb chardev without fbcon is very much a real idea. This way
you should be able to run old userspace that uses fbdev directly for
drawing, but your console needs are served by a userspace console running
on top of drm.

vt switching gets a bit more entertaining, but I thought logind has all
the glue already to make that happen. Worst case you need a tiny launcher
tool to get your userspace console out of the way while you launch a fbdev
using application, but I think correctly implement the vt ioctls to switch
to graphics mode /should/ work automatically.

I do agree that this is only really a good idea with drm drivers, since
those do not rely on any of the fbdev infrastructure like the notifier
under discussion.

I'm pretty sure what Florian is looking for has no dependency
on VT, fbcon or logind, but I'm only guessing based on the
information I see in the public Android source trees.

My understanding is that the Android recovery application is a
graphical tool that accesses the framebuffer directly and
is controlled using the volume and power buttons on a phone.

I suppose making CONFIG_FB_NOTIFIER optional for FB (on by
default if any of the consumers of the notification are turned
on) would not be a bad direction to go in general and also
address Florian's link error, but that doesn't solve the
more general concern about a third-party fb.ko module on a
kernel that was explicitly built with FB disabled.

The GKI defconfig was initially done at a time where one could
not have CONFIG_FBDEV_EMULATION and CONFIG_FB_DEVICE without
pulling in the entire fbdev module, but now that is possible.
Maybe that is something that Android could now include?

Alternatively, I wonder if that recovery image could be changed
to access the screen through the /dev/dri/ interfaces? I have
no experience in using those without Xorg or Wayland, is that
a sensible thing to do?

Uh ... I think I'm confused about the requirements. Does android's
recovery image need fbdev (meaning /dev/fb chardevs), or does it need
fbcon?

Note that fbcon runs (or well, should run) totally fine on top of drm
drivers without the fb notifier. This wasn't the case a few years ago
(because fbcon also used that notifier), but nowadays fb notifiers are
only needed for legacy fbdev drivers. So could it be that this "need fb
notifier" requirement is a leftover from rather old kernel versions and
not actually needed anymore?

I think we should nail the actual requirements here first before jumping
to solutions ...

Right, let's wait for Florian to reply. From what he said earlier
though, the only reason that the notifiers are getting in the
way is the link error you get from trying to load a separately
built fb.ko module on a kernel that was built with FB=n / FB_CORE=n,
so I don't think he even cares about notifiers, only about
allowing the recovery application to mmap() the framebuffer.

Right, we do not really care about notifiers AFAICT. Based upon this discussion there has been an action on our side to stop making use of the FB subsystem for recovery and use the full blow DRM driver instead.

While we get there, though I still see some value into this patch (or a v2, that is). I have a v2 ready if you think there is some value in pursuing that route, if not, we can stop there.
--
Florian

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux