Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755471AbdLTPWa (ORCPT ); Wed, 20 Dec 2017 10:22:30 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:46766 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755381AbdLTPW0 (ORCPT ); Wed, 20 Dec 2017 10:22:26 -0500 X-Google-Smtp-Source: ACJfBovAPOcT/wAmIJcEZZT9ZbwpYvXxI7W4M+Uk3MjKwwSk2C+lUwoQscRtDaBFJ2Yusj6bUdl2gCsw1UUvuf8k8NE= 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:22:25 +0100 X-Google-Sender-Auth: IfmHwxsh7qmNMjB7Jt1Y5e9GX1U 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: 2900 Lines: 59 On Wed, Dec 20, 2017 at 4:19 PM, Daniel Vetter wrote: > 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. *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