From: Max Staudt <mstaudt@suse.de>
To: "Bartlomiej Zolnierkiewicz" <b.zolnierkie@samsung.com>,
"Linux Fbdev development list" <linux-fbdev@vger.kernel.org>,
michal@markovi.net, 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>,
"Bero Rosenkränzer" <bernhard.rosenkranzer@linaro.org>,
philm@manjaro.org
Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash
Date: Wed, 20 Dec 2017 15:10:54 +0100 [thread overview]
Message-ID: <3549c7c9-6d26-047a-ed4e-a2c81c44c079@suse.de> (raw)
In-Reply-To: <20171220094355.GJ26573@phenom.ffwll.local>
On 12/20/2017 10:43 AM, 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:
>>> 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.
Sorry, I was unclear.
It's Plymouth's ShowDelay that, unintentionally, papers over this bug.
The driver loading bug will happen with any user based splash - it's not limited to Plymouth.
On the other hand, if you don't start a graphical application before having loaded the final graphics driver, everything is good and there is no race.
So, module loading works as intended ;)
>>> 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.
Hmm. Are you sure it's okay to SIG these processes just because someone else has decided to unload a driver? That is counter to everything else that I've seen so far.
Also, is it even feasible, implementation wise?
>>> 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.
Hmm, that still makes us wait until userspace has appeared...
And the reason I built it into *con is because the logic for appearing/disappearing is basically the same, and in this chain it makes sense for the bootsplash show/hide logic to be chained behind *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 :-)
I'm afraid I don't have the time to write an in-kernel terminal emulator, thus the wish to build upon the existing one...
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-12-20 14:10 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 19:47 [RFC PATCH v2 00/13] Kernel based bootsplash 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 [this message]
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=3549c7c9-6d26-047a-ed4e-a2c81c44c079@suse.de \
--to=mstaudt@suse.de \
--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=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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).