dri-devel Archive on lore.kernel.org
 help / color / Atom feed
From: Ray Strode <halfline@gmail.com>
To: Max Staudt <mstaudt@suse.de>
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>,
	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 10:21:53 -0500
Message-ID: <CAA_Uwz+Px-+-b6TLtPBnSk9zMmayOAR5=Tv7Jd0xkXgkB6hE5w@mail.gmail.com> (raw)
In-Reply-To: <48846920-4244-763c-a23b-44f42ac2c2c6@suse.de>

Hi,

> The problem that I am stumbling upon is different:
>  - the system starts with an FB driver
>  - after the ShowDelay time, Plymouth opens /dev/fb0
>  - the system finally loads the DRM driver, which tries to kick the previous FB driver
>  - loading the DRM driver fails because Plymouth still has the previous /dev/fb0 open
So the thing to realize is, that using /dev/fb is a last ditch effort
by plymouth to make
things work. It's basically a compat hack to keep vga=0x318 working
and also a nod
to embedded systems that just have /dev/fb and don't have a kms driver.  If we
fall back to /dev/fb we lose, as mentioned before, multi-monitor
support. And it's a
legacy, deprecated api.

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 ?

> If you have a better way of calling it, I'd be glad to learn.
> Maybe "grabbing the VT", "taking ownership of the VT", ...?
I don't care what we call it, I just didn't understand what you were
saying before.
I think i'd say "manages vt switching", but whatever.

> 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.

> [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.
(though it should use drm subsystem apis not graphics subsystem apis,
/dev/fb is going
the way of the dodo)

> 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.
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.

> 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.

--Ray
_______________________________________________
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
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 [this message]
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='CAA_Uwz+Px-+-b6TLtPBnSk9zMmayOAR5=Tv7Jd0xkXgkB6hE5w@mail.gmail.com' \
    --to=halfline@gmail.com \
    --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=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