dri-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: "Linux Fbdev development list" <linux-fbdev@vger.kernel.org>,
	michal@markovi.net,
	"Bartlomiej Zolnierkiewicz" <b.zolnierkie@samsung.com>,
	sndirsch@suse.com, "Oliver Neukum" <oneukum@suse.com>,
	"Takashi Iwai" <tiwai@suse.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Max Staudt" <mstaudt@suse.de>,
	philm@manjaro.org,
	"Bero Rosenkränzer" <bernhard.rosenkranzer@linaro.org>
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> (raw)
In-Reply-To: <e9734508-9b2c-0c18-f6ef-6ca984a33b32@baylibre.com>

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 <mstaudt@suse.de> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply index

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-13 19:47 Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 01/13] bootsplash: Initial implementation showing black screen Max Staudt
2017-12-13 23:55   ` Randy Dunlap
2017-12-14 15:37     ` Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 02/13] bootsplash: Add file reading and picture rendering Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing Max Staudt
2017-12-13 21:35   ` Daniel Vetter
2017-12-14 15:36     ` Max Staudt
2017-12-19 12:23       ` Daniel Vetter
2017-12-19 13:34         ` Max Staudt
2017-12-19 13:57           ` Daniel Vetter
2017-12-19 14:07             ` Oliver Neukum
2017-12-31 12:53               ` Alan Cox
2018-01-03 18:04                 ` Max Staudt
2017-12-19 15:41             ` Max Staudt
2017-12-19 16:02               ` Daniel Vetter
2017-12-19 16:23                 ` Max Staudt
2017-12-20  9:45                   ` Daniel Vetter
2017-12-19 16:09               ` Daniel Vetter
2017-12-19 16:26                 ` Max Staudt
2017-12-19 21:01               ` Ray Strode
2017-12-20 13:14                 ` Max Staudt
2017-12-20 15:35                   ` Ray Strode
2017-12-20 16:52                     ` Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 04/13] bootsplash: Add corner positioning Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 05/13] bootsplash: Add animation support Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 06/13] vt: Redraw bootsplash fully on console_unblank Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 07/13] vt: Add keyboard hook to disable bootsplash Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 08/13] sysrq: Disable bootsplash on SAK Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 09/13] fbcon: Disable bootsplash on oops Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 10/13] Documentation: Add bootsplash main documentation Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 11/13] bootsplash: sysfs entries to load and unload files Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 12/13] tools/bootsplash: Add a basic splash file creation tool Max Staudt
2017-12-13 19:47 ` [RFC PATCH v2 13/13] tools/bootsplash: Add script and data to create sample file Max Staudt
2017-12-13 19:52 ` [RFC PATCH v2 00/13] Kernel based bootsplash Max Staudt
2017-12-19 16:16 ` Daniel Vetter
2017-12-19 17:04   ` Max Staudt
2017-12-19 17:26     ` Daniel Vetter
2017-12-19 18:40       ` Max Staudt
2017-12-20  9:43         ` Daniel Vetter
2017-12-20 10:06           ` Neil Armstrong
2017-12-20 10:14             ` Daniel Vetter [this message]
2017-12-20 14:55               ` Max Staudt
2017-12-20 15:11                 ` Daniel Vetter
2017-12-20 15:19                   ` Daniel Vetter
2017-12-20 15:22                     ` Daniel Vetter
2017-12-20 16:23                     ` Max Staudt
2017-12-20 16:15                   ` Max Staudt
2017-12-31 12:44                   ` Alan Cox
2018-01-03 18:00                     ` Max Staudt
2017-12-20 14:16             ` Max Staudt
2017-12-20 14:10           ` Max Staudt
2017-12-31 12:35         ` Alan Cox
2018-01-03 17:56           ` Max Staudt
2017-12-19 20:30     ` Ray Strode
2017-12-20 13:03       ` Max Staudt
2017-12-20 15:21         ` Ray Strode
2017-12-20 16:44           ` Max Staudt
2017-12-21 14:51             ` Ray Strode
2017-12-21 16:32               ` Max Staudt
2017-12-20 11:08   ` Johannes Thumshirn
2017-12-20 11:22     ` Daniel Stone
2017-12-20 12:48       ` Johannes Thumshirn
2017-12-29 17:13   ` Jani Nikula
2018-01-03 17:38     ` Max Staudt
2017-12-21  9:48 ` Daniel Vetter
2017-12-21 16:52   ` Max Staudt
2017-12-21 15:00 ` Philip Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171220101421.GM26573@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=b.zolnierkie@samsung.com \
    --cc=bernhard.rosenkranzer@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal@markovi.net \
    --cc=mstaudt@suse.de \
    --cc=narmstrong@baylibre.com \
    --cc=oneukum@suse.com \
    --cc=philm@manjaro.org \
    --cc=sndirsch@suse.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

dri-devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dri-devel/0 dri-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dri-devel dri-devel/ https://lore.kernel.org/dri-devel \
		dri-devel@lists.freedesktop.org
	public-inbox-index dri-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.freedesktop.lists.dri-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git