On Wed, Dec 20, 2017 at 4:19 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt <mstaudt@xxxxxxx> 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. *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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
