[RFC PATCH v2 00/13] Kernel based bootsplash

[Daniel Vetter]

On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt <mstaudt at suse.de> wrote:
>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>>> 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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch