From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Date: Wed, 20 Dec 2017 10:14:21 +0000 Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Message-Id: <20171220101421.GM26573@phenom.ffwll.local> List-Id: 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> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Neil Armstrong Cc: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Max Staudt , philm@manjaro.org, Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= On Wed, Dec 20, 2017 at 11:06:34AM +0100, Neil Armstrong wrote: > On 20/12/2017 10:43, Daniel Vetter wrote: > > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: > >> On 12/19/2017 06:26 PM, Daniel Vetter wrote: > >>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote: > >>>> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a difference anyway if they're powerful enough to run Linux. As long as the bootsplash is shown, no fbcon drawing operations are executed, so there is no expensive scrolling or such to hog the system. > >>> > >>> It's too big, and those folks tend to be super picky about space. > >> > >> I know, they really are. > >> > >> However, given just how big and clunky modern systems have become, I > >> raise my doubts about a few extra KB for fbcon code to be relevant. > >> > >> My feeling is that the kernel splash probably saves even more space on > >> the userspace side than it adds on the kernel side, thus netting a > >> reduction in overall code size. > >> > >> > >>> So essentially you're telling me that on a current general purpose > >>> distro the gfx driver loading is a dumpster fire, and we're fixing > >>> this by ignoring it an adding a hole new layer on top. That doesn't > >>> sound like any kind of good idea to me. > >> > >> Yes. It is a vast improvement over the status quo, and people are asking > >> for it. And the bootsplash layer can be moved elsewhere, just change the > >> hooks and keep the loading/rendering. > >> > >> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It > >> just mustn't be done 100% carelessly. > > > > You've talked about using sleep and stuff to paper over races. That > > doesn't sound good at all. > > > >>> So if just using drm for everything isn't possible (since drm drivers > >>> can at least in theory be hotunplugged), can we at least fix the > >>> existing fbdev kernel bugs? Not being able to unplug a drm driver when > >>> it's still open sounds like a rather serious issues that probably > >>> should be fixed anyway ... so we're better able to hotunplug an fbdev > >>> driver when it's in use. > >> > >> I don't see it as a bug. The fbdev driver gets unloaded as much as > >> possible, but as long as a userspace application keeps the address_space > >> mmap()ed, there's nothing we can do, short of forcibly removing it and > >> segfaulting the process the next time it tries to render something. Am I > >> missing something? > > > > I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering > > in a sighandler and abort if you hit that. In drm we try to be a bit > > better and keep things around until userspace has gone. > > > >>> Also I'm not clear at all on the "papering over races with sleeps" > >>> part. DRM drivers shouldn't be racy when getting loaded ... > >> > >> The DRM driver loading isn't racy, but the fbdev can't be fully unloaded > >> while Plymouth has the address_space mmap()ed. If Plymouth sleeps until > >> drivers that are included in initramfs are (hopefully) loaded, then it > >> will forego using its FB backend. > >> > >> A solution we've experimented with is dropping the FB backend from > >> Plymouth. It instantly fixed the busy video RAM bug. However it made the > >> folks relying on efifb very, very unhappy. > >> > >> > >>> Or we get simpledrm merged (for efifb and vesafb support) and someone > >>> types the xendrm driver (there is floating around, it's just old) and > >>> we could forget about any real fbdev drivers except the drm based > >>> ones. > >> > >> And drmcon, unless we come up with a better idea than hooking into the *con driver. > > > > If we have everything as drm drivers, you can just use plymouth (with no > > fbdev backend ofc) and everyone is happy. Including the efifb folks (it's > > simply going to be called efidrmfb or something like that). So no idea why > > you need a *con. > > > >> Sure, that'd help a lot. But what do we do until then? > > > > Make it happen? Twiddling thumbs is an option too ofc, but it tends to not > > result in results :-) > > > > Cheers, Daniel > > > > My 2cents about this patchset: > You did a good job about all the animation and splash logic, but for me all this fbcon > stuff is a huge hack, please use a standard and modern display subsystem en leave fbcon > die alone.... > > My DRM ARM systems would love to have such bootsplash, so please, make it happen using DRM > then leave the fbcon based stuff like efifb migrate to DRM in a second time ! 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). But I'm really not sold on the current integration path being anywhere near close to a good idea long-term. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Date: Wed, 20 Dec 2017 11:14:21 +0100 Message-ID: <20171220101421.GM26573@phenom.ffwll.local> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) by gabe.freedesktop.org (Postfix) with ESMTPS id 261FD89CB2 for ; Wed, 20 Dec 2017 10:14:26 +0000 (UTC) Received: by mail-wm0-x232.google.com with SMTP id t8so8737989wmc.3 for ; Wed, 20 Dec 2017 02:14:26 -0800 (PST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Neil Armstrong Cc: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Max Staudt , philm@manjaro.org, Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBEZWMgMjAsIDIwMTcgYXQgMTE6MDY6MzRBTSArMDEwMCwgTmVpbCBBcm1zdHJvbmcg d3JvdGU6Cj4gT24gMjAvMTIvMjAxNyAxMDo0MywgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+IE9u IFR1ZSwgRGVjIDE5LCAyMDE3IGF0IDA3OjQwOjEyUE0gKzAxMDAsIE1heCBTdGF1ZHQgd3JvdGU6 Cj4gPj4gT24gMTIvMTkvMjAxNyAwNjoyNiBQTSwgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+Pj4g T24gVHVlLCBEZWMgMTksIDIwMTcgYXQgNjowNCBQTSwgTWF4IFN0YXVkdCA8bXN0YXVkdEBzdXNl LmRlPiB3cm90ZToKPiA+Pj4+IFdlbGwsIHRob3NlIGNvdWxkIGVuYWJsZSBmYmNvbiBpZiB0aGV5 IHdhbnQgdGhlIGJvb3RzcGxhc2guIFNob3VsZG4ndCBtYWtlIGEgZGlmZmVyZW5jZSBhbnl3YXkg aWYgdGhleSdyZSBwb3dlcmZ1bCBlbm91Z2ggdG8gcnVuIExpbnV4LiBBcyBsb25nIGFzIHRoZSBi b290c3BsYXNoIGlzIHNob3duLCBubyBmYmNvbiBkcmF3aW5nIG9wZXJhdGlvbnMgYXJlIGV4ZWN1 dGVkLCBzbyB0aGVyZSBpcyBubyBleHBlbnNpdmUgc2Nyb2xsaW5nIG9yIHN1Y2ggdG8gaG9nIHRo ZSBzeXN0ZW0uCj4gPj4+Cj4gPj4+IEl0J3MgdG9vIGJpZywgYW5kIHRob3NlIGZvbGtzIHRlbmQg dG8gYmUgc3VwZXIgcGlja3kgYWJvdXQgc3BhY2UuCj4gPj4KPiA+PiBJIGtub3csIHRoZXkgcmVh bGx5IGFyZS4KPiA+Pgo+ID4+IEhvd2V2ZXIsIGdpdmVuIGp1c3QgaG93IGJpZyBhbmQgY2x1bmt5 IG1vZGVybiBzeXN0ZW1zIGhhdmUgYmVjb21lLCBJCj4gPj4gcmFpc2UgbXkgZG91YnRzIGFib3V0 IGEgZmV3IGV4dHJhIEtCIGZvciBmYmNvbiBjb2RlIHRvIGJlIHJlbGV2YW50Lgo+ID4+Cj4gPj4g TXkgZmVlbGluZyBpcyB0aGF0IHRoZSBrZXJuZWwgc3BsYXNoIHByb2JhYmx5IHNhdmVzIGV2ZW4g bW9yZSBzcGFjZSBvbgo+ID4+IHRoZSB1c2Vyc3BhY2Ugc2lkZSB0aGFuIGl0IGFkZHMgb24gdGhl IGtlcm5lbCBzaWRlLCB0aHVzIG5ldHRpbmcgYQo+ID4+IHJlZHVjdGlvbiBpbiBvdmVyYWxsIGNv ZGUgc2l6ZS4KPiA+Pgo+ID4+Cj4gPj4+IFNvIGVzc2VudGlhbGx5IHlvdSdyZSB0ZWxsaW5nIG1l IHRoYXQgb24gYSBjdXJyZW50IGdlbmVyYWwgcHVycG9zZQo+ID4+PiBkaXN0cm8gdGhlIGdmeCBk cml2ZXIgbG9hZGluZyBpcyBhIGR1bXBzdGVyIGZpcmUsIGFuZCB3ZSdyZSBmaXhpbmcKPiA+Pj4g dGhpcyBieSBpZ25vcmluZyBpdCBhbiBhZGRpbmcgYSBob2xlIG5ldyBsYXllciBvbiB0b3AuIFRo YXQgZG9lc24ndAo+ID4+PiBzb3VuZCBsaWtlIGFueSBraW5kIG9mIGdvb2QgaWRlYSB0byBtZS4K PiA+Pgo+ID4+IFllcy4gSXQgaXMgYSB2YXN0IGltcHJvdmVtZW50IG92ZXIgdGhlIHN0YXR1cyBx dW8sIGFuZCBwZW9wbGUgYXJlIGFza2luZwo+ID4+IGZvciBpdC4gQW5kIHRoZSBib290c3BsYXNo IGxheWVyIGNhbiBiZSBtb3ZlZCBlbHNld2hlcmUsIGp1c3QgY2hhbmdlIHRoZQo+ID4+IGhvb2tz IGFuZCBrZWVwIHRoZSBsb2FkaW5nL3JlbmRlcmluZy4KPiA+Pgo+ID4+IEFsc28sIGdmeCBkcml2 ZXIgbG9hZGluZyBpc24ndCBhIGR1bXBzdGVyIGZpcmUsIGl0IG1vc3RseSBqdXN0IHdvcmtzLiBJ dAo+ID4+IGp1c3QgbXVzdG4ndCBiZSBkb25lIDEwMCUgY2FyZWxlc3NseS4KPiA+IAo+ID4gWW91 J3ZlIHRhbGtlZCBhYm91dCB1c2luZyBzbGVlcCBhbmQgc3R1ZmYgdG8gcGFwZXIgb3ZlciByYWNl cy4gVGhhdAo+ID4gZG9lc24ndCBzb3VuZCBnb29kIGF0IGFsbC4KPiA+IAo+ID4+PiBTbyBpZiBq dXN0IHVzaW5nIGRybSBmb3IgZXZlcnl0aGluZyBpc24ndCBwb3NzaWJsZSAoc2luY2UgZHJtIGRy aXZlcnMKPiA+Pj4gY2FuIGF0IGxlYXN0IGluIHRoZW9yeSBiZSBob3R1bnBsdWdnZWQpLCBjYW4g d2UgYXQgbGVhc3QgZml4IHRoZQo+ID4+PiBleGlzdGluZyBmYmRldiBrZXJuZWwgYnVncz8gTm90 IGJlaW5nIGFibGUgdG8gdW5wbHVnIGEgZHJtIGRyaXZlciB3aGVuCj4gPj4+IGl0J3Mgc3RpbGwg b3BlbiBzb3VuZHMgbGlrZSBhIHJhdGhlciBzZXJpb3VzIGlzc3VlcyB0aGF0IHByb2JhYmx5Cj4g Pj4+IHNob3VsZCBiZSBmaXhlZCBhbnl3YXkgLi4uIHNvIHdlJ3JlIGJldHRlciBhYmxlIHRvIGhv dHVucGx1ZyBhbiBmYmRldgo+ID4+PiBkcml2ZXIgd2hlbiBpdCdzIGluIHVzZS4KPiA+Pgo+ID4+ IEkgZG9uJ3Qgc2VlIGl0IGFzIGEgYnVnLiBUaGUgZmJkZXYgZHJpdmVyIGdldHMgdW5sb2FkZWQg YXMgbXVjaCBhcwo+ID4+IHBvc3NpYmxlLCBidXQgYXMgbG9uZyBhcyBhIHVzZXJzcGFjZSBhcHBs aWNhdGlvbiBrZWVwcyB0aGUgYWRkcmVzc19zcGFjZQo+ID4+IG1tYXAoKWVkLCB0aGVyZSdzIG5v dGhpbmcgd2UgY2FuIGRvLCBzaG9ydCBvZiBmb3JjaWJseSByZW1vdmluZyBpdCBhbmQKPiA+PiBz ZWdmYXVsdGluZyB0aGUgcHJvY2VzcyB0aGUgbmV4dCB0aW1lIGl0IHRyaWVzIHRvIHJlbmRlciBz b21ldGhpbmcuIEFtIEkKPiA+PiBtaXNzaW5nIHNvbWV0aGluZz8KPiA+IAo+ID4gSSBndWVzcyB5 b3UgY291bGQgcmVtYXAgdGhhdCB0b28gLi4uIEJ1dCB5ZWFoIFNJR0JVUyBmdHcuIFdyYXAgcmVu ZGVyaW5nCj4gPiBpbiBhIHNpZ2hhbmRsZXIgYW5kIGFib3J0IGlmIHlvdSBoaXQgdGhhdC4gSW4g ZHJtIHdlIHRyeSB0byBiZSBhIGJpdAo+ID4gYmV0dGVyIGFuZCBrZWVwIHRoaW5ncyBhcm91bmQg dW50aWwgdXNlcnNwYWNlIGhhcyBnb25lLgo+ID4gCj4gPj4+IEFsc28gSSdtIG5vdCBjbGVhciBh dCBhbGwgb24gdGhlICJwYXBlcmluZyBvdmVyIHJhY2VzIHdpdGggc2xlZXBzIgo+ID4+PiBwYXJ0 LiBEUk0gZHJpdmVycyBzaG91bGRuJ3QgYmUgcmFjeSB3aGVuIGdldHRpbmcgbG9hZGVkIC4uLgo+ ID4+Cj4gPj4gVGhlIERSTSBkcml2ZXIgbG9hZGluZyBpc24ndCByYWN5LCBidXQgdGhlIGZiZGV2 IGNhbid0IGJlIGZ1bGx5IHVubG9hZGVkCj4gPj4gd2hpbGUgUGx5bW91dGggaGFzIHRoZSBhZGRy ZXNzX3NwYWNlIG1tYXAoKWVkLiBJZiBQbHltb3V0aCBzbGVlcHMgdW50aWwKPiA+PiBkcml2ZXJz IHRoYXQgYXJlIGluY2x1ZGVkIGluIGluaXRyYW1mcyBhcmUgKGhvcGVmdWxseSkgbG9hZGVkLCB0 aGVuIGl0Cj4gPj4gd2lsbCBmb3JlZ28gdXNpbmcgaXRzIEZCIGJhY2tlbmQuCj4gPj4KPiA+PiBB IHNvbHV0aW9uIHdlJ3ZlIGV4cGVyaW1lbnRlZCB3aXRoIGlzIGRyb3BwaW5nIHRoZSBGQiBiYWNr ZW5kIGZyb20KPiA+PiBQbHltb3V0aC4gSXQgaW5zdGFudGx5IGZpeGVkIHRoZSBidXN5IHZpZGVv IFJBTSBidWcuIEhvd2V2ZXIgaXQgbWFkZSB0aGUKPiA+PiBmb2xrcyByZWx5aW5nIG9uIGVmaWZi IHZlcnksIHZlcnkgdW5oYXBweS4KPiA+Pgo+ID4+Cj4gPj4+IE9yIHdlIGdldCBzaW1wbGVkcm0g bWVyZ2VkIChmb3IgZWZpZmIgYW5kIHZlc2FmYiBzdXBwb3J0KSBhbmQgc29tZW9uZQo+ID4+PiB0 eXBlcyB0aGUgeGVuZHJtIGRyaXZlciAodGhlcmUgaXMgZmxvYXRpbmcgYXJvdW5kLCBpdCdzIGp1 c3Qgb2xkKSBhbmQKPiA+Pj4gd2UgY291bGQgZm9yZ2V0IGFib3V0IGFueSByZWFsIGZiZGV2IGRy aXZlcnMgZXhjZXB0IHRoZSBkcm0gYmFzZWQKPiA+Pj4gb25lcy4KPiA+Pgo+ID4+IEFuZCBkcm1j b24sIHVubGVzcyB3ZSBjb21lIHVwIHdpdGggYSBiZXR0ZXIgaWRlYSB0aGFuIGhvb2tpbmcgaW50 byB0aGUgKmNvbiBkcml2ZXIuCj4gPiAKPiA+IElmIHdlIGhhdmUgZXZlcnl0aGluZyBhcyBkcm0g ZHJpdmVycywgeW91IGNhbiBqdXN0IHVzZSBwbHltb3V0aCAod2l0aCBubwo+ID4gZmJkZXYgYmFj a2VuZCBvZmMpIGFuZCBldmVyeW9uZSBpcyBoYXBweS4gSW5jbHVkaW5nIHRoZSBlZmlmYiBmb2xr cyAoaXQncwo+ID4gc2ltcGx5IGdvaW5nIHRvIGJlIGNhbGxlZCBlZmlkcm1mYiBvciBzb21ldGhp bmcgbGlrZSB0aGF0KS4gU28gbm8gaWRlYSB3aHkKPiA+IHlvdSBuZWVkIGEgKmNvbi4KPiA+IAo+ ID4+IFN1cmUsIHRoYXQnZCBoZWxwIGEgbG90LiBCdXQgd2hhdCBkbyB3ZSBkbyB1bnRpbCB0aGVu Pwo+ID4gCj4gPiBNYWtlIGl0IGhhcHBlbj8gVHdpZGRsaW5nIHRodW1icyBpcyBhbiBvcHRpb24g dG9vIG9mYywgYnV0IGl0IHRlbmRzIHRvIG5vdAo+ID4gcmVzdWx0IGluIHJlc3VsdHMgOi0pCj4g PiAKPiA+IENoZWVycywgRGFuaWVsCj4gPiAKPiAKPiBNeSAyY2VudHMgYWJvdXQgdGhpcyBwYXRj aHNldDoKPiBZb3UgZGlkIGEgZ29vZCBqb2IgYWJvdXQgYWxsIHRoZSBhbmltYXRpb24gYW5kIHNw bGFzaCBsb2dpYywgYnV0IGZvciBtZSBhbGwgdGhpcyBmYmNvbgo+IHN0dWZmIGlzIGEgaHVnZSBo YWNrLCBwbGVhc2UgdXNlIGEgc3RhbmRhcmQgYW5kIG1vZGVybiBkaXNwbGF5IHN1YnN5c3RlbSBl biBsZWF2ZSBmYmNvbgo+IGRpZSBhbG9uZS4uLi4KPiAKPiBNeSBEUk0gQVJNIHN5c3RlbXMgd291 bGQgbG92ZSB0byBoYXZlIHN1Y2ggYm9vdHNwbGFzaCwgc28gcGxlYXNlLCBtYWtlIGl0IGhhcHBl biB1c2luZyBEUk0KPiB0aGVuIGxlYXZlIHRoZSBmYmNvbiBiYXNlZCBzdHVmZiBsaWtlIGVmaWZi IG1pZ3JhdGUgdG8gRFJNIGluIGEgc2Vjb25kIHRpbWUgIQoKYnR3IHNpbmNlIEknbSBwcm9iYWJs eSBzb3VuZGluZyBhIGJpdCB0b28gZ3J1bXB5IGhlcmU6IEknZCB2ZXJ5IG11Y2gKc3VwcG9ydCB0 aGlzLiBJIHRoaW5rIGJvb3RzcGxhc2ggaW4ga2VybmVsIGhhcyBhIGJ1bmNoIG9mIHVzZXMsIGFu ZCBpdApzaG91bGRuJ3QgYmUgaGFyZCB0byBnZXQgbm9uLXN1c2UgcGVvcGxlIHRvIGNoZWVyIGZv ciBpdCAobWFrZXMgbWVyZ2luZwplYXNpZXIgaWYgaXQncyBub3QganVzdCBhIG9uZS1vZmYgaGFj aykuCgpCdXQgSSdtIHJlYWxseSBub3Qgc29sZCBvbiB0aGUgY3VycmVudCBpbnRlZ3JhdGlvbiBw YXRoIGJlaW5nIGFueXdoZXJlCm5lYXIgY2xvc2UgdG8gYSBnb29kIGlkZWEgbG9uZy10ZXJtLgot RGFuaWVsCi0tIApEYW5pZWwgVmV0dGVyClNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3Jh dGlvbgpodHRwOi8vYmxvZy5mZndsbC5jaApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5m cmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754913AbdLTKOd (ORCPT ); Wed, 20 Dec 2017 05:14:33 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:43668 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754194AbdLTKO0 (ORCPT ); Wed, 20 Dec 2017 05:14:26 -0500 X-Google-Smtp-Source: ACJfBouWxYPWOMs3vspmji25vqBgclblfTLycGIKZ4R1MlNlbhr2gk1hN3e/sfYFYrCW8f1xL64Low== Date: Wed, 20 Dec 2017 11:14:21 +0100 From: Daniel Vetter To: Neil Armstrong Cc: Max Staudt , Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= , philm@manjaro.org Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Message-ID: <20171220101421.GM26573@phenom.ffwll.local> Mail-Followup-To: Neil Armstrong , Max Staudt , Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= , philm@manjaro.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.13.0-1-amd64 User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 20, 2017 at 11:06:34AM +0100, Neil Armstrong wrote: > On 20/12/2017 10:43, Daniel Vetter wrote: > > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: > >> On 12/19/2017 06:26 PM, Daniel Vetter wrote: > >>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote: > >>>> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a difference anyway if they're powerful enough to run Linux. As long as the bootsplash is shown, no fbcon drawing operations are executed, so there is no expensive scrolling or such to hog the system. > >>> > >>> It's too big, and those folks tend to be super picky about space. > >> > >> I know, they really are. > >> > >> However, given just how big and clunky modern systems have become, I > >> raise my doubts about a few extra KB for fbcon code to be relevant. > >> > >> My feeling is that the kernel splash probably saves even more space on > >> the userspace side than it adds on the kernel side, thus netting a > >> reduction in overall code size. > >> > >> > >>> So essentially you're telling me that on a current general purpose > >>> distro the gfx driver loading is a dumpster fire, and we're fixing > >>> this by ignoring it an adding a hole new layer on top. That doesn't > >>> sound like any kind of good idea to me. > >> > >> Yes. It is a vast improvement over the status quo, and people are asking > >> for it. And the bootsplash layer can be moved elsewhere, just change the > >> hooks and keep the loading/rendering. > >> > >> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It > >> just mustn't be done 100% carelessly. > > > > You've talked about using sleep and stuff to paper over races. That > > doesn't sound good at all. > > > >>> So if just using drm for everything isn't possible (since drm drivers > >>> can at least in theory be hotunplugged), can we at least fix the > >>> existing fbdev kernel bugs? Not being able to unplug a drm driver when > >>> it's still open sounds like a rather serious issues that probably > >>> should be fixed anyway ... so we're better able to hotunplug an fbdev > >>> driver when it's in use. > >> > >> I don't see it as a bug. The fbdev driver gets unloaded as much as > >> possible, but as long as a userspace application keeps the address_space > >> mmap()ed, there's nothing we can do, short of forcibly removing it and > >> segfaulting the process the next time it tries to render something. Am I > >> missing something? > > > > I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering > > in a sighandler and abort if you hit that. In drm we try to be a bit > > better and keep things around until userspace has gone. > > > >>> Also I'm not clear at all on the "papering over races with sleeps" > >>> part. DRM drivers shouldn't be racy when getting loaded ... > >> > >> The DRM driver loading isn't racy, but the fbdev can't be fully unloaded > >> while Plymouth has the address_space mmap()ed. If Plymouth sleeps until > >> drivers that are included in initramfs are (hopefully) loaded, then it > >> will forego using its FB backend. > >> > >> A solution we've experimented with is dropping the FB backend from > >> Plymouth. It instantly fixed the busy video RAM bug. However it made the > >> folks relying on efifb very, very unhappy. > >> > >> > >>> Or we get simpledrm merged (for efifb and vesafb support) and someone > >>> types the xendrm driver (there is floating around, it's just old) and > >>> we could forget about any real fbdev drivers except the drm based > >>> ones. > >> > >> And drmcon, unless we come up with a better idea than hooking into the *con driver. > > > > If we have everything as drm drivers, you can just use plymouth (with no > > fbdev backend ofc) and everyone is happy. Including the efifb folks (it's > > simply going to be called efidrmfb or something like that). So no idea why > > you need a *con. > > > >> Sure, that'd help a lot. But what do we do until then? > > > > Make it happen? Twiddling thumbs is an option too ofc, but it tends to not > > result in results :-) > > > > Cheers, Daniel > > > > My 2cents about this patchset: > You did a good job about all the animation and splash logic, but for me all this fbcon > stuff is a huge hack, please use a standard and modern display subsystem en leave fbcon > die alone.... > > My DRM ARM systems would love to have such bootsplash, so please, make it happen using DRM > then leave the fbcon based stuff like efifb migrate to DRM in a second time ! 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). But I'm really not sold on the current integration path being anywhere near close to a good idea long-term. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch