[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171231124457.12e954f8@alans-desktop>
Date: Sun, 31 Dec 2017 12:44:57 +0000
From: Alan Cox <gnomes@...rguk.ukuu.org.uk>
To: Daniel Vetter <daniel@...ll.ch>
Cc: Max Staudt <mstaudt@...e.de>,
Neil Armstrong <narmstrong@...libre.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
michal@...kovi.net, sndirsch@...e.com,
Oliver Neukum <oneukum@...e.com>,
Takashi Iwai <tiwai@...e.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Bero Rosenkränzer
<bernhard.rosenkranzer@...aro.org>, philm@...jaro.org
Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
It wouldn't be in kernel on such a device, it'll be in the bootstrap
before (or on a dual core device quite possibly while) the kernel data is
being uncompressed. Most displays need some time to stabilize clocks and
PLLs so you have to get the mode set up really really early on embedded
devices where in some cases you've got regulatory requirements to show
something on the display really really quickly. Consumers perceive a
second from on to displaying something as sluggish on a fixed function
device.
> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt subsystem at all.
> Definitely not your general purpose distro.
Probably no console or tty layer even present, no keyboard drivers, no
mouse.
Alan
Powered by blists - more mailing lists