Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755581AbdLTPTF (ORCPT ); Wed, 20 Dec 2017 10:19:05 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:34119 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755227AbdLTPTD (ORCPT ); Wed, 20 Dec 2017 10:19:03 -0500 X-Google-Smtp-Source: ACJfBosj8YHmo66fyba8vuWZW2UgHtT7px7hRntp865Xv3JYMiYR1ZqI0o+TxFJ5njx50FuNZrcYkOck8pfhmtXUkSs= MIME-Version: 1.0 X-Originating-IP: [2a02:168:5635:0:39d2:f87e:2033:9f6] In-Reply-To: References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> <2f8a1a08-911d-a511-2968-4d89418ac212@suse.de> <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> <20171220094355.GJ26573@phenom.ffwll.local> <20171220101421.GM26573@phenom.ffwll.local> <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> From: Daniel Vetter Date: Wed, 20 Dec 2017 16:19:01 +0100 X-Google-Sender-Auth: 9ny0-nCG-XD8IGC8XRoM6by8PG8 Message-ID: Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash To: Max Staudt Cc: Neil Armstrong , Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , =?UTF-8?Q?Bero_Rosenkr=C3=A4nzer?= , philm@manjaro.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2587 Lines: 54 On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote: > On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt 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