On Wed, Dec 20, 2017 at 4:19 PM, Daniel Vetter [off-list ref] wrote:

On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter [off-list ref] wrote:

quoted

On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt [off-list ref] wrote:

quoted

On 12/20/2017 11:14 AM, Daniel Vetter wrote:

quoted

btw since I'm probably sounding a bit too grumpy here: I'd very much
support this. I think bootsplash in kernel has a bunch of uses, and it
shouldn't be hard to get non-suse people to cheer for it (makes merging
easier if it's not just a one-off hack).

Thank you!

As it seems, other people and distros are already interested - for example Manjaro.

It's also a chance to (maybe in the near future) integrate with a splash painted by EFI and/or GRUB, before userspace has even started.

Maybe I've sounded too optimistic now.

So fundamentally I don't think an in-kernel bootsplash is a bad idea.
But most likely you want this on a highly embedded system, which
probably is compiled for your exact hw, with pretty much everything
built in. Also, no fbcon, maybe even no vt subsystem at all.
Definitely not your general purpose distro.

Your proposal to work on top of fbcon doesn't fix that niche.

Now for your problem, which seems to be to have a working bootsplash
for a general purpose distro, specifically for the bug where plymouth
prevents the real drm driver from loading: Adding an in-kernel
bootsplash doesn't make any sense, at least not to me. Instead I think
the right action is to fix the problem, both in the kernel and in
userspace.

All the problems below have fairly simple solutions, but there's imo
no point in talking technical solutions for specific problems when
we're trying to fix the wrong problem.

Aside: The problem you think you need the vt/console subsystem for is
simple to fix with plain kms: kms works without fbdev, fbcon and the
entire vt subsystem. Dislay ownership is controlled through the drm
master concept. That's the exact same trick that we're using already
to figure out whether fbdev (not just fbcon) is allowed to touch the
display hw.

So yeah, there's a solution, and a modern system definitely would not
want to get encumbered with the entire vt subsystem to be able to use
a bootsplash. David Herrman had the entire pile prototyped btw,
including userspace console on top of drm, emergency log on top of
drm, and replacement for simpledrm. Adding an in-kernel boot splash
would be fairly simple for this setup. It's just that no one else
cared enough to get it merged.

*replacement for efifb/vesafb in the form of simpledrm. The
in-userspace fbcon is called kmscon, so also exists already. The
emergency boot splash thing was called drmlog iirc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch