dri-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Max Staudt <mstaudt@suse.de>
To: Ray Strode <halfline@gmail.com>
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" <linux-kernel@vger.kernel.org>,
	"Bero Rosenkränzer" <bernhard.rosenkranzer@linaro.org>
Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash
Date: Wed, 20 Dec 2017 17:44:31 +0100
Message-ID: <872ee7d0-ad33-f68a-c859-0865682faaea@suse.de> (raw)
In-Reply-To: <CAA_Uwz+Px-+-b6TLtPBnSk9zMmayOAR5=Tv7Jd0xkXgkB6hE5w@mail.gmail.com>

On 12/20/2017 04:21 PM, Ray Strode wrote:
> If we've reached the scenario you're discussing above, the real
> failure is that the KMS
> driver took too long to load. DRM is the platform graphics api.  If
> it's not loading
> timely enough to show graphics then that's the problem!  It sounds
> like maybe in the
> above bug, you're just failing to load the drm driver in the initrd ?

This case needs to be handled.

Again, please read my bug report.

When the user changes graphics cards, the initrd does not contain the new driver. It's in the rootfs, if at all.

If it does happen to be on the rootfs, then it is potentially loaded after Plymouth has already opened /dev/fb0. And then the bug occurs.

Please don't say that I'm to blame for changing my graphics card. This is not fair.

And I have to admit, it's not even necessarily a bug. It's just the nature of the kernel/userspace split. All I know is that the boot failing due to this is not right, and horrible to debug the next time it happens to someone.

>> And then, if something causes Plymouth to sense a new device (such as Plymouth
>>  thinking that udev coldplug is complete), it will open the device, and as part of that,
>> call VT_SETMODE. This is unexpected, since "plymouth deactivate" should keep it
>> from doing this. And Plymouth's code architecture is such that this bug is hard to fix.
> If what you're describing is happening, this does sound like a bug. I
> don't think it
> should be hard to fix, if it's a problem. I'll look into it.

Thank you!

It'd be nice to see this bug fixed, as it happens only occasionally (as is the nature of a race condition), and was thus really hard to debug. I'm sure it can drive people insane, as they try to find out whether they've disabled Ctrl-Alt-Fx in their xorg.conf, but really it's Plymouth getting the system into a bad state. I probably owe a bald patch on my head to this bug.

>> [I] have decided to write a kernel-based replacement to simplify things and to show a
>> splash as early as possible. It just avoids all of this complexity.
> So, for the record, I don't actually have a problem with you doing a
> kernel based splash.


It's really just meant as an alternative. I've heard enough people who'd prefer it over Plymouth, but Plymouth is just as important as it is much more feature-rich.

>> This is the sleep that I mean.
>> On the one hand, it is this delay that makes most users not notice the
>> "busy VRAM bug". If the DRM driver that replaces the FB driver is included in the
>> initramfs, then in most cases, it will be loaded before the 5 seconds are up. However,
>> if the driver is loaded after these 5 seconds have elapsed, then Plymouth will have
>> opened /dev/fb0 and the modprobe fails.
> Think of this from a user perspective.  If the screen is black for 15 seconds
> (or something) before a splash is shown, then we've already hit a
> problem! That's like 15
> seconds of time where the user is wondering if their system is broken.

This is exactly where the kernel bootsplash is useful. Since it starts even before any userspace program is loaded, it can close this gap.

I've even tried it in combination with Plymouth: Plymouth is just another graphical application, so it simply pops up "on top", just like X would. The two splashes integrate flawlessly.

> But I don't think that actually happens in practice.  I think (maybe?)
> the situation you're
> hitting is your drm driver isn't starting to get loaded until N
> seconds after boot has started,
> because it's not in the initrd.  So the fix is to put it in the initrd.
No. See above.

One could argue that one could put all DRM drivers into the initrd. Ubuntu does this, and the initrd is ~40 MB in size. Not nice.

And even then, the initrd could be outdated for some reason. Maybe it's a developer machine. Nobody would expect the boot to hang/fail because of this problem.

>> On the other hand, what is the motivation for this delay?
> As I said earlier, the motivation for the delay is to avoid showing a
> splash for systems that
> boot in 4 seconds or something. At that point a splash is just getting
> in the way.
>>  If Plymouth were to display the splash instantly on a system that needs 0.5 seconds to
>> boot, then the splash would flash for 0.5 seconds.
> No, flashing a splash for half a second would be a bug. (again think
> of things from a user
> perpective).  Plymouth splashes have animations at the end to
> transition the user to the
>  login screen.  Normally those animations don't contribute to boot
> time, because we know
> when boot will finish from prior boot data.  But if boot were 0.5
> seconds long, then those
>  animations would contribute 2 to 3 seconds to boot time, and if boot
> is 0.5 seconds long
> showing a splash is pointless.
>> But with the delay, a system that needs 5.5 seconds to boot will also flash it for 0.5 seconds.
>> Either way, the splash will just flash for a moment.
> again, we don't blink the splash on and off. we have transition animations.
>> The delay only changes which systems are affected. However, if you set the delay to 0,
>> you'll run into the bug I described above.
> Then put the drm driver in the initramfs so you fix your bug !
>> This is a design problem, hidden by a needless delay.
> really don't see how it is.

Ah, I see. I admit I wasn't aware of such transitions and boot timings.

So let's take SUSE. They don't have a finishing transition, the splash simply stops and is hidden at once.
Such a splash makes sense to be shown instantly, right?

So the startup delay could be reduced to 0. Except that that would mean running into the initrd "bug".

dri-devel mailing list

  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
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 [this message]
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:

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

  git send-email \
    --in-reply-to=872ee7d0-ad33-f68a-c859-0865682faaea@suse.de \
    --to=mstaudt@suse.de \
    --cc=b.zolnierkie@samsung.com \
    --cc=bernhard.rosenkranzer@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=halfline@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal@markovi.net \
    --cc=oneukum@suse.com \
    --cc=philm@manjaro.org \
    --cc=sndirsch@suse.com \
    --cc=tiwai@suse.com \


* 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 \
	public-inbox-index dri-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

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