From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755341AbdLTNOi (ORCPT ); Wed, 20 Dec 2017 08:14:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:51525 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755215AbdLTNOe (ORCPT ); Wed, 20 Dec 2017 08:14:34 -0500 Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing To: Ray Strode Cc: b.zolnierkie@samsung.com, linux-fbdev@vger.kernel.org, michal@markovi.net, 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 References: <20171213194755.3409-1-mstaudt@suse.de> <20171213194755.3409-4-mstaudt@suse.de> <20171213213506.GD26573@phenom.ffwll.local> <20171219122313.GE26573@phenom.ffwll.local> <8bbb0497-4a10-2f81-0040-6e7cd4e7353c@suse.de> <20171219135715.GG26573@phenom.ffwll.local> <8036b6a6-6ed5-2f34-e854-1c397a9f34d4@suse.de> From: Max Staudt Message-ID: Date: Wed, 20 Dec 2017 14:14:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/19/2017 10:01 PM, Ray Strode wrote: > Hi, > > On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote: >> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a >> functional extension of that. It just happens that fbcon sits on top of FB, so I >> work with what I get. >> >> And the console in turn happens to work on all FB and KMS drivers, so it >> makes users of all kinds of drivers happy. In fact, that's why the FB emulation >> in KMS drivers came to be in the first place, if I remember right - to ensure >> fbcon continues to work. > > But what about multi-monitor? what about hidpi screens? Ideally you want > each monitor to show the splash in a way that best fits that monitor. Actually, I don't want that :) This was a design decision that I've made to keep the code small and simple to audit. As it is, the simple bootsplash code will make 99% of people happy. It includes positioning of objects in corners and in the center, and a background color, and thus can render something that doesn't look funny in all but the most extreme cases. I've made this decision from the point of view of someone who wants to ship a general purpose distribution. If you have a look around and compare this to e.g. the Windows or Mac OS X bootsplashes, the possibilities that my kernel code provides already surpasses them. If you really want such sophisticated features, supplanting the initial bootsplash with Plymouth (or not using it at all) is a better solution. In my opinion, it is overengineering, at least for kernel code. So... I'll just take what the fbdev emulation gives me. In most cases (single screen systems), this looks good. In most remaining cases, you have two identical monitors that show exactly the same thing. And whatever remains can live with whatever mode the DRM driver decides to set for the fbdev emulation. As for HiDPI, if you're working on an embedded device with a fixed screen size - say a phone - you can easily include a huge picture the size of the screen in the bootsplash. Again, it's feature creep now. Apple just centers a, well, an apple in the middle of the screen. Windows may even boot in 640x480 and then do a mode switch when showing the desktop (not sure whether this is still true with the latest version). Neither of them scales for HiDPI, and neither cares about multiple monitors. People are happy. So in the end, it's a matter of taste. I agree that in user space, exploring these features is fun. But in kernel space, it's definitely important to keep the code short and simple. I'm convinced that I've found a good balance :) Max From mboxrd@z Thu Jan 1 00:00:00 1970 From: Max Staudt Date: Wed, 20 Dec 2017 13:14:31 +0000 Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing Message-Id: List-Id: References: <20171213194755.3409-1-mstaudt@suse.de> <20171213194755.3409-4-mstaudt@suse.de> <20171213213506.GD26573@phenom.ffwll.local> <20171219122313.GE26573@phenom.ffwll.local> <8bbb0497-4a10-2f81-0040-6e7cd4e7353c@suse.de> <20171219135715.GG26573@phenom.ffwll.local> <8036b6a6-6ed5-2f34-e854-1c397a9f34d4@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ray Strode 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 On 12/19/2017 10:01 PM, Ray Strode wrote: > Hi, > > On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote: >> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a >> functional extension of that. It just happens that fbcon sits on top of FB, so I >> work with what I get. >> >> And the console in turn happens to work on all FB and KMS drivers, so it >> makes users of all kinds of drivers happy. In fact, that's why the FB emulation >> in KMS drivers came to be in the first place, if I remember right - to ensure >> fbcon continues to work. > > But what about multi-monitor? what about hidpi screens? Ideally you want > each monitor to show the splash in a way that best fits that monitor. Actually, I don't want that :) This was a design decision that I've made to keep the code small and simple to audit. As it is, the simple bootsplash code will make 99% of people happy. It includes positioning of objects in corners and in the center, and a background color, and thus can render something that doesn't look funny in all but the most extreme cases. I've made this decision from the point of view of someone who wants to ship a general purpose distribution. If you have a look around and compare this to e.g. the Windows or Mac OS X bootsplashes, the possibilities that my kernel code provides already surpasses them. If you really want such sophisticated features, supplanting the initial bootsplash with Plymouth (or not using it at all) is a better solution. In my opinion, it is overengineering, at least for kernel code. So... I'll just take what the fbdev emulation gives me. In most cases (single screen systems), this looks good. In most remaining cases, you have two identical monitors that show exactly the same thing. And whatever remains can live with whatever mode the DRM driver decides to set for the fbdev emulation. As for HiDPI, if you're working on an embedded device with a fixed screen size - say a phone - you can easily include a huge picture the size of the screen in the bootsplash. Again, it's feature creep now. Apple just centers a, well, an apple in the middle of the screen. Windows may even boot in 640x480 and then do a mode switch when showing the desktop (not sure whether this is still true with the latest version). Neither of them scales for HiDPI, and neither cares about multiple monitors. People are happy. So in the end, it's a matter of taste. I agree that in user space, exploring these features is fun. But in kernel space, it's definitely important to keep the code short and simple. I'm convinced that I've found a good balance :) Max From mboxrd@z Thu Jan 1 00:00:00 1970 From: Max Staudt Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing Date: Wed, 20 Dec 2017 14:14:31 +0100 Message-ID: References: <20171213194755.3409-1-mstaudt@suse.de> <20171213194755.3409-4-mstaudt@suse.de> <20171213213506.GD26573@phenom.ffwll.local> <20171219122313.GE26573@phenom.ffwll.local> <8bbb0497-4a10-2f81-0040-6e7cd4e7353c@suse.de> <20171219135715.GG26573@phenom.ffwll.local> <8036b6a6-6ed5-2f34-e854-1c397a9f34d4@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 59F9389D77 for ; Wed, 20 Dec 2017 13:14:34 +0000 (UTC) In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ray Strode 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 List-Id: dri-devel@lists.freedesktop.org T24gMTIvMTkvMjAxNyAxMDowMSBQTSwgUmF5IFN0cm9kZSB3cm90ZToKPiBIaSwKPiAKPiBPbiBU dWUsIERlYyAxOSwgMjAxNyBhdCAxMDo0MSBBTSwgTWF4IFN0YXVkdCA8bXN0YXVkdEBzdXNlLmRl PiB3cm90ZToKPj4gSSdtIGhvb2tpbmcgaW50byB0aGUgaW4ta2VybmVsIHRlcm1pbmFsIGVtdWxh dG9yLCBiZWNhdXNlIHRoZSBib290c3BsYXNoIGlzIGEKPj4gZnVuY3Rpb25hbCBleHRlbnNpb24g b2YgdGhhdC4gSXQganVzdCBoYXBwZW5zIHRoYXQgZmJjb24gc2l0cyBvbiB0b3Agb2YgRkIsIHNv IEkKPj4gd29yayB3aXRoIHdoYXQgSSBnZXQuCj4+Cj4+IEFuZCB0aGUgY29uc29sZSBpbiB0dXJu IGhhcHBlbnMgdG8gd29yayBvbiBhbGwgRkIgYW5kIEtNUyBkcml2ZXJzLCBzbyBpdAo+PiBtYWtl cyB1c2VycyBvZiBhbGwga2luZHMgb2YgZHJpdmVycyBoYXBweS4gSW4gZmFjdCwgdGhhdCdzIHdo eSB0aGUgRkIgZW11bGF0aW9uCj4+IGluIEtNUyBkcml2ZXJzIGNhbWUgdG8gYmUgaW4gdGhlIGZp cnN0IHBsYWNlLCBpZiBJIHJlbWVtYmVyIHJpZ2h0IC0gdG8gZW5zdXJlCj4+IGZiY29uIGNvbnRp bnVlcyB0byB3b3JrLgo+IAo+IEJ1dCB3aGF0IGFib3V0IG11bHRpLW1vbml0b3I/IHdoYXQgYWJv dXQgaGlkcGkgc2NyZWVucz8gIElkZWFsbHkgeW91IHdhbnQKPiBlYWNoIG1vbml0b3IgdG8gc2hv dyB0aGUgc3BsYXNoIGluIGEgd2F5IHRoYXQgYmVzdCBmaXRzIHRoYXQgbW9uaXRvci4KCkFjdHVh bGx5LCBJIGRvbid0IHdhbnQgdGhhdCA6KQoKVGhpcyB3YXMgYSBkZXNpZ24gZGVjaXNpb24gdGhh dCBJJ3ZlIG1hZGUgdG8ga2VlcCB0aGUgY29kZSBzbWFsbCBhbmQgc2ltcGxlIHRvIGF1ZGl0LgpB cyBpdCBpcywgdGhlIHNpbXBsZSBib290c3BsYXNoIGNvZGUgd2lsbCBtYWtlIDk5JSBvZiBwZW9w bGUgaGFwcHkuIEl0IGluY2x1ZGVzIHBvc2l0aW9uaW5nIG9mIG9iamVjdHMgaW4gY29ybmVycyBh bmQgaW4gdGhlIGNlbnRlciwgYW5kIGEgYmFja2dyb3VuZCBjb2xvciwgYW5kIHRodXMgY2FuIHJl bmRlciBzb21ldGhpbmcgdGhhdCBkb2Vzbid0IGxvb2sgZnVubnkgaW4gYWxsIGJ1dCB0aGUgbW9z dCBleHRyZW1lIGNhc2VzLgoKSSd2ZSBtYWRlIHRoaXMgZGVjaXNpb24gZnJvbSB0aGUgcG9pbnQg b2YgdmlldyBvZiBzb21lb25lIHdobyB3YW50cyB0byBzaGlwIGEgZ2VuZXJhbCBwdXJwb3NlIGRp c3RyaWJ1dGlvbi4gSWYgeW91IGhhdmUgYSBsb29rIGFyb3VuZCBhbmQgY29tcGFyZSB0aGlzIHRv IGUuZy4gdGhlIFdpbmRvd3Mgb3IgTWFjIE9TIFggYm9vdHNwbGFzaGVzLCB0aGUgcG9zc2liaWxp dGllcyB0aGF0IG15IGtlcm5lbCBjb2RlIHByb3ZpZGVzIGFscmVhZHkgc3VycGFzc2VzIHRoZW0u CgpJZiB5b3UgcmVhbGx5IHdhbnQgc3VjaCBzb3BoaXN0aWNhdGVkIGZlYXR1cmVzLCBzdXBwbGFu dGluZyB0aGUgaW5pdGlhbCBib290c3BsYXNoICB3aXRoIFBseW1vdXRoIChvciBub3QgdXNpbmcg aXQgYXQgYWxsKSBpcyBhIGJldHRlciBzb2x1dGlvbi4gSW4gbXkgb3BpbmlvbiwgaXQgaXMgb3Zl cmVuZ2luZWVyaW5nLCBhdCBsZWFzdCBmb3Iga2VybmVsIGNvZGUuCgoKU28uLi4gSSdsbCBqdXN0 IHRha2Ugd2hhdCB0aGUgZmJkZXYgZW11bGF0aW9uIGdpdmVzIG1lLiBJbiBtb3N0IGNhc2VzIChz aW5nbGUgc2NyZWVuIHN5c3RlbXMpLCB0aGlzIGxvb2tzIGdvb2QuIEluIG1vc3QgcmVtYWluaW5n IGNhc2VzLCB5b3UgaGF2ZSB0d28gaWRlbnRpY2FsIG1vbml0b3JzIHRoYXQgc2hvdyBleGFjdGx5 IHRoZSBzYW1lIHRoaW5nLiBBbmQgd2hhdGV2ZXIgcmVtYWlucyBjYW4gbGl2ZSB3aXRoIHdoYXRl dmVyIG1vZGUgdGhlIERSTSBkcml2ZXIgZGVjaWRlcyB0byBzZXQgZm9yIHRoZSBmYmRldiBlbXVs YXRpb24uCgoKQXMgZm9yIEhpRFBJLCBpZiB5b3UncmUgd29ya2luZyBvbiBhbiBlbWJlZGRlZCBk ZXZpY2Ugd2l0aCBhIGZpeGVkIHNjcmVlbiBzaXplIC0gc2F5IGEgcGhvbmUgLSB5b3UgY2FuIGVh c2lseSBpbmNsdWRlIGEgaHVnZSBwaWN0dXJlIHRoZSBzaXplIG9mIHRoZSBzY3JlZW4gaW4gdGhl IGJvb3RzcGxhc2guCgoKQWdhaW4sIGl0J3MgZmVhdHVyZSBjcmVlcCBub3cuIEFwcGxlIGp1c3Qg Y2VudGVycyBhLCB3ZWxsLCBhbiBhcHBsZSBpbiB0aGUgbWlkZGxlIG9mIHRoZSBzY3JlZW4uIFdp bmRvd3MgbWF5IGV2ZW4gYm9vdCBpbiA2NDB4NDgwIGFuZCB0aGVuIGRvIGEgbW9kZSBzd2l0Y2gg d2hlbiBzaG93aW5nIHRoZSBkZXNrdG9wIChub3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgc3RpbGwg dHJ1ZSB3aXRoIHRoZSBsYXRlc3QgdmVyc2lvbikuIE5laXRoZXIgb2YgdGhlbSBzY2FsZXMgZm9y IEhpRFBJLCBhbmQgbmVpdGhlciBjYXJlcyBhYm91dCBtdWx0aXBsZSBtb25pdG9ycy4gUGVvcGxl IGFyZSBoYXBweS4KCgpTbyBpbiB0aGUgZW5kLCBpdCdzIGEgbWF0dGVyIG9mIHRhc3RlLiBJIGFn cmVlIHRoYXQgaW4gdXNlciBzcGFjZSwgZXhwbG9yaW5nIHRoZXNlIGZlYXR1cmVzIGlzIGZ1bi4g QnV0IGluIGtlcm5lbCBzcGFjZSwgaXQncyBkZWZpbml0ZWx5IGltcG9ydGFudCB0byBrZWVwIHRo ZSBjb2RlIHNob3J0IGFuZCBzaW1wbGUuIEknbSBjb252aW5jZWQgdGhhdCBJJ3ZlIGZvdW5kIGEg Z29vZCBiYWxhbmNlIDopCgoKTWF4Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVk ZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RyaS1kZXZlbAo=