From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula Date: Fri, 29 Dec 2017 17:13:39 +0000 Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Message-Id: <878tdlzccc.fsf@intel.com> List-Id: References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> In-Reply-To: <20171219161630.GI26573@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Daniel Vetter , Max Staudt Cc: linux-fbdev@vger.kernel.org, michal@markovi.net, b.zolnierkie@samsung.com, sndirsch@suse.com, oneukum@suse.com, tiwai@suse.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, bernhard.rosenkranzer@linaro.org, philm@manjaro.org On Tue, 19 Dec 2017, Daniel Vetter wrote: > On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote: >> Dear fbdev and fbcon developers, >> >> Thank you very much for your input for the first patch series. >> >> I've included your feedback into this second roll, and kindly ask for >> your opinion on the new patch series. > > Ok I've realized that my assumptions about why you need this aren't > holding up. > > So from reading these patches it sounded like you want an in-kernel boot > splash because that would be on the display faster than a userspace one > like plymouth. That's the only reasons I can see for this (if there's > another good justification, please bring it up). > > I only know of very embedded setups (tv top boxes, in vehicle > entertainment) where that kind of "time to first image" really matters, > and those systems: > - have a real hw kms driver > - don't have fbcon or fbdev emulation enabled (except for some closed > source stacks that are a bit slow to adapt to the new world, and we > don't care about those in gfx). > > But from discussions it sounds like you very much want to use this on > servers, which makes 0 sense to me. On a server something like plymouth > should do a perfectly reasonable job. > > So, why exactly do we need this? Okay, I'll take another step back from the implementation and most of the discussion here, and look at what *I* would like to see on screen when I have my user hat on and my kernel developer hat securely stowed away. I think the first issue is the boot manager (e.g. grub) messing up whatever the BIOS or GOP or whatever drew. If I don't touch any buttons, I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC some BIOSes let you set up your own splash if you like, though that's not really relevant for me. So already the boot manager takeover is a problem. The next issue is the framebuffer driver takeover. It's not unlike the above, just one step further. If you like your grub image to stay there, let it stay there. (Or, if the boot manager was nice enough to not mess up the screen, let the BIOS image stay there.) All the way to KMS and userspace. IMHO the user friendly experience is already gone by the time we reach any kernel/userspace bootsplash. We want our command-line tools to STFU if they don't have anything interesting to say. As a user, 99.99+% of the time I don't care what grub or dmesg have to say. Of course, with the kernel developer hat on, I want all of the clues every time in case something goes wrong. But this shouldn't have to be mutually exclusive. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Date: Fri, 29 Dec 2017 19:13:39 +0200 Message-ID: <878tdlzccc.fsf@intel.com> References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id 85142898C7 for ; Fri, 29 Dec 2017 17:13:45 +0000 (UTC) In-Reply-To: <20171219161630.GI26573@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter , Max Staudt Cc: linux-fbdev@vger.kernel.org, michal@markovi.net, b.zolnierkie@samsung.com, sndirsch@suse.com, oneukum@suse.com, tiwai@suse.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, bernhard.rosenkranzer@linaro.org, philm@manjaro.org List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCAxOSBEZWMgMjAxNywgRGFuaWVsIFZldHRlciA8ZGFuaWVsQGZmd2xsLmNoPiB3cm90 ZToKPiBPbiBXZWQsIERlYyAxMywgMjAxNyBhdCAwODo0Nzo0MlBNICswMTAwLCBNYXggU3RhdWR0 IHdyb3RlOgo+PiBEZWFyIGZiZGV2IGFuZCBmYmNvbiBkZXZlbG9wZXJzLAo+PiAKPj4gVGhhbmsg eW91IHZlcnkgbXVjaCBmb3IgeW91ciBpbnB1dCBmb3IgdGhlIGZpcnN0IHBhdGNoIHNlcmllcy4K Pj4gCj4+IEkndmUgaW5jbHVkZWQgeW91ciBmZWVkYmFjayBpbnRvIHRoaXMgc2Vjb25kIHJvbGws IGFuZCBraW5kbHkgYXNrIGZvcgo+PiB5b3VyIG9waW5pb24gb24gdGhlIG5ldyBwYXRjaCBzZXJp ZXMuCj4KPiBPayBJJ3ZlIHJlYWxpemVkIHRoYXQgbXkgYXNzdW1wdGlvbnMgYWJvdXQgd2h5IHlv dSBuZWVkIHRoaXMgYXJlbid0Cj4gaG9sZGluZyB1cC4KPgo+IFNvIGZyb20gcmVhZGluZyB0aGVz ZSBwYXRjaGVzIGl0IHNvdW5kZWQgbGlrZSB5b3Ugd2FudCBhbiBpbi1rZXJuZWwgYm9vdAo+IHNw bGFzaCBiZWNhdXNlIHRoYXQgd291bGQgYmUgb24gdGhlIGRpc3BsYXkgZmFzdGVyIHRoYW4gYSB1 c2Vyc3BhY2Ugb25lCj4gbGlrZSBwbHltb3V0aC4gVGhhdCdzIHRoZSBvbmx5IHJlYXNvbnMgSSBj YW4gc2VlIGZvciB0aGlzIChpZiB0aGVyZSdzCj4gYW5vdGhlciBnb29kIGp1c3RpZmljYXRpb24s IHBsZWFzZSBicmluZyBpdCB1cCkuCj4KPiBJIG9ubHkga25vdyBvZiB2ZXJ5IGVtYmVkZGVkIHNl dHVwcyAodHYgdG9wIGJveGVzLCBpbiB2ZWhpY2xlCj4gZW50ZXJ0YWlubWVudCkgd2hlcmUgdGhh dCBraW5kIG9mICJ0aW1lIHRvIGZpcnN0IGltYWdlIiByZWFsbHkgbWF0dGVycywKPiBhbmQgdGhv c2Ugc3lzdGVtczoKPiAtIGhhdmUgYSByZWFsIGh3IGttcyBkcml2ZXIKPiAtIGRvbid0IGhhdmUg ZmJjb24gb3IgZmJkZXYgZW11bGF0aW9uIGVuYWJsZWQgKGV4Y2VwdCBmb3Igc29tZSBjbG9zZWQK PiAgIHNvdXJjZSBzdGFja3MgdGhhdCBhcmUgYSBiaXQgc2xvdyB0byBhZGFwdCB0byB0aGUgbmV3 IHdvcmxkLCBhbmQgd2UKPiAgIGRvbid0IGNhcmUgYWJvdXQgdGhvc2UgaW4gZ2Z4KS4KPgo+IEJ1 dCBmcm9tIGRpc2N1c3Npb25zIGl0IHNvdW5kcyBsaWtlIHlvdSB2ZXJ5IG11Y2ggd2FudCB0byB1 c2UgdGhpcyBvbgo+IHNlcnZlcnMsIHdoaWNoIG1ha2VzIDAgc2Vuc2UgdG8gbWUuIE9uIGEgc2Vy dmVyIHNvbWV0aGluZyBsaWtlIHBseW1vdXRoCj4gc2hvdWxkIGRvIGEgcGVyZmVjdGx5IHJlYXNv bmFibGUgam9iLgo+Cj4gU28sIHdoeSBleGFjdGx5IGRvIHdlIG5lZWQgdGhpcz8KCk9rYXksIEkn bGwgdGFrZSBhbm90aGVyIHN0ZXAgYmFjayBmcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgbW9z dCBvZgp0aGUgZGlzY3Vzc2lvbiBoZXJlLCBhbmQgbG9vayBhdCB3aGF0ICpJKiB3b3VsZCBsaWtl IHRvIHNlZSBvbiBzY3JlZW4Kd2hlbiBJIGhhdmUgbXkgdXNlciBoYXQgb24gYW5kIG15IGtlcm5l bCBkZXZlbG9wZXIgaGF0IHNlY3VyZWx5IHN0b3dlZAphd2F5LgoKSSB0aGluayB0aGUgZmlyc3Qg aXNzdWUgaXMgdGhlIGJvb3QgbWFuYWdlciAoZS5nLiBncnViKSBtZXNzaW5nIHVwCndoYXRldmVy IHRoZSBCSU9TIG9yIEdPUCBvciB3aGF0ZXZlciBkcmV3LiBJZiBJIGRvbid0IHRvdWNoIGFueSBi dXR0b25zLApJJ2QgcHJlZmVyIHRoZSBMZW5vdm8gb3IgVkFJTyBvciBOVUMgb3Igd2hhdGV2ZXIg bG9nbyBzdGF5IHRoZXJlLiBJSVJDCnNvbWUgQklPU2VzIGxldCB5b3Ugc2V0IHVwIHlvdXIgb3du IHNwbGFzaCBpZiB5b3UgbGlrZSwgdGhvdWdoIHRoYXQncwpub3QgcmVhbGx5IHJlbGV2YW50IGZv ciBtZS4gU28gYWxyZWFkeSB0aGUgYm9vdCBtYW5hZ2VyIHRha2VvdmVyIGlzIGEKcHJvYmxlbS4K ClRoZSBuZXh0IGlzc3VlIGlzIHRoZSBmcmFtZWJ1ZmZlciBkcml2ZXIgdGFrZW92ZXIuIEl0J3Mg bm90IHVubGlrZSB0aGUKYWJvdmUsIGp1c3Qgb25lIHN0ZXAgZnVydGhlci4gSWYgeW91IGxpa2Ug eW91ciBncnViIGltYWdlIHRvIHN0YXkgdGhlcmUsCmxldCBpdCBzdGF5IHRoZXJlLiAoT3IsIGlm IHRoZSBib290IG1hbmFnZXIgd2FzIG5pY2UgZW5vdWdoIHRvIG5vdCBtZXNzCnVwIHRoZSBzY3Jl ZW4sIGxldCB0aGUgQklPUyBpbWFnZSBzdGF5IHRoZXJlLikgQWxsIHRoZSB3YXkgdG8gS01TIGFu ZAp1c2Vyc3BhY2UuCgpJTUhPIHRoZSB1c2VyIGZyaWVuZGx5IGV4cGVyaWVuY2UgaXMgYWxyZWFk eSBnb25lIGJ5IHRoZSB0aW1lIHdlIHJlYWNoCmFueSBrZXJuZWwvdXNlcnNwYWNlIGJvb3RzcGxh c2guIFdlIHdhbnQgb3VyIGNvbW1hbmQtbGluZSB0b29scyB0byBTVEZVCmlmIHRoZXkgZG9uJ3Qg aGF2ZSBhbnl0aGluZyBpbnRlcmVzdGluZyB0byBzYXkuIEFzIGEgdXNlciwgOTkuOTkrJSBvZgp0 aGUgdGltZSBJIGRvbid0IGNhcmUgd2hhdCBncnViIG9yIGRtZXNnIGhhdmUgdG8gc2F5LgoKT2Yg Y291cnNlLCB3aXRoIHRoZSBrZXJuZWwgZGV2ZWxvcGVyIGhhdCBvbiwgSSB3YW50IGFsbCBvZiB0 aGUgY2x1ZXMKZXZlcnkgdGltZSBpbiBjYXNlIHNvbWV0aGluZyBnb2VzIHdyb25nLiBCdXQgdGhp cyBzaG91bGRuJ3QgaGF2ZSB0byBiZQptdXR1YWxseSBleGNsdXNpdmUuCgoKQlIsCkphbmkuCgoK LS0gCkphbmkgTmlrdWxhLCBJbnRlbCBPcGVuIFNvdXJjZSBUZWNobm9sb2d5IENlbnRlcgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFp bGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751626AbdL2RNr (ORCPT ); Fri, 29 Dec 2017 12:13:47 -0500 Received: from mga03.intel.com ([134.134.136.65]:62078 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751506AbdL2RNp (ORCPT ); Fri, 29 Dec 2017 12:13:45 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,477,1508828400"; d="scan'208";a="15359743" From: Jani Nikula To: Daniel Vetter , Max Staudt Cc: linux-fbdev@vger.kernel.org, michal@markovi.net, b.zolnierkie@samsung.com, sndirsch@suse.com, oneukum@suse.com, tiwai@suse.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, philm@manjaro.org, bernhard.rosenkranzer@linaro.org Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash In-Reply-To: <20171219161630.GI26573@phenom.ffwll.local> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> Date: Fri, 29 Dec 2017 19:13:39 +0200 Message-ID: <878tdlzccc.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 Dec 2017, Daniel Vetter wrote: > On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote: >> Dear fbdev and fbcon developers, >> >> Thank you very much for your input for the first patch series. >> >> I've included your feedback into this second roll, and kindly ask for >> your opinion on the new patch series. > > Ok I've realized that my assumptions about why you need this aren't > holding up. > > So from reading these patches it sounded like you want an in-kernel boot > splash because that would be on the display faster than a userspace one > like plymouth. That's the only reasons I can see for this (if there's > another good justification, please bring it up). > > I only know of very embedded setups (tv top boxes, in vehicle > entertainment) where that kind of "time to first image" really matters, > and those systems: > - have a real hw kms driver > - don't have fbcon or fbdev emulation enabled (except for some closed > source stacks that are a bit slow to adapt to the new world, and we > don't care about those in gfx). > > But from discussions it sounds like you very much want to use this on > servers, which makes 0 sense to me. On a server something like plymouth > should do a perfectly reasonable job. > > So, why exactly do we need this? Okay, I'll take another step back from the implementation and most of the discussion here, and look at what *I* would like to see on screen when I have my user hat on and my kernel developer hat securely stowed away. I think the first issue is the boot manager (e.g. grub) messing up whatever the BIOS or GOP or whatever drew. If I don't touch any buttons, I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC some BIOSes let you set up your own splash if you like, though that's not really relevant for me. So already the boot manager takeover is a problem. The next issue is the framebuffer driver takeover. It's not unlike the above, just one step further. If you like your grub image to stay there, let it stay there. (Or, if the boot manager was nice enough to not mess up the screen, let the BIOS image stay there.) All the way to KMS and userspace. IMHO the user friendly experience is already gone by the time we reach any kernel/userspace bootsplash. We want our command-line tools to STFU if they don't have anything interesting to say. As a user, 99.99+% of the time I don't care what grub or dmesg have to say. Of course, with the kernel developer hat on, I want all of the clues every time in case something goes wrong. But this shouldn't have to be mutually exclusive. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center