From: Max Staudt <mstaudt@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
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>,
philm@manjaro.org,
"Bero Rosenkränzer" <bernhard.rosenkranzer@linaro.org>
Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
Date: Tue, 19 Dec 2017 17:23:52 +0100 [thread overview]
Message-ID: <24fd8767-bdf2-0073-2161-a0cf3b61780d@suse.de> (raw)
In-Reply-To: <CAKMK7uHgPheSuGc6v3aSxzaJ_BNMGRs3zZ=Mv7M_us37QS8-sg@mail.gmail.com>
On 12/19/2017 05:02 PM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt <mstaudt@suse.de> wrote:
>> On 12/19/2017 02:57 PM, Daniel Vetter wrote:
>>> The problem is that defio is totally not how a real driver works.
>>
>> But they do exist and I can't ignore them.
>>
>> I'm afraid I don't understand - why are those, such as xenfb, not real drivers?
>
> I mean kms drivers. The problem is that the magic mapping that fbdev
> expects is real pain. Everyone else, including kms, expects an
> explicit flush operation. So instead of hacking around even more with
> the defio corner cases that don't work, I'm suggesting we just add
> that flush operation. At least internally.
>
> Fixing kms drivers to implement a better defio is probably not a
> reasonable investement of time.
Ah yes, I understand now, you mean that KMS drivers have explicit flush, and defio is a hack to retrofit such drivers to an API that never supported a flush operation (the fbdev API), but always used to expose the video memory directly. Right?
If yes, then I agree. Fixing the defio in the KMS drivers wouldn't even solve my problem - I'd still need to implement flush. So might as well care about the flush straight away, yep!
>>> So
>>> preferrably bootsplash would use kms directly, and use the explict dirtyfb
>>> callback.
>>
>> Sure, if I'd be hooking into drmcon, that would be great.
>>
>> But drmcon doesn't exist yet, so it doesn't get us further to talk about a bootsplash on KMS :(
>>
>> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a functional extension of that. It just happens that fbcon sits on top of FB, so I work with what I get.
>
> Why do you need a console for a boot splash? You're not drawing
> console output afaiui ... And even your current fbdev-based
> implementation only interfaces with fbcon insofar as you're making
> sure fbcon doesn't wreak your boot splash. Or I'm missing something
> somewhere.
Errr... true. I'll answer it below, where you ask again.
>> In fact, if I define fbops->flush(), defio drivers can still add their own proper flushing function, so everybody wins. I like that, see below.
>
> tbh I'd forget about ever touching any of the existing fbdev drivers.
> Imo just not worth the time investement.
Fair point. It's optional anyway, and can still be done (quickly and painlessly) on demand.
Since my goal here is making a nice bootsplash, I'll touch as few drivers as I can.
>>>> So, what shall I do? As it is, the hack is already specific to devices that really, really need it.
>>>>
>>>> Would you like me to extend the FB API or not?
>>>
>>> Yes. Well for real I'd like you to do kms, so maybe you need to explain
>>> why exactly you absolutely have to use fbdev (aka which driver isn't
>>> supported by drm that you want to enable this on).
>>
>> See Oliver's reply - we have plenty of fb-only systems deployed in the real world. Think Xen. Think AArch64 with efifb. Think any system before the KMS driver is loaded (which is a case that the splash is supposed to handle).
>
> And you need a real pretty boot-splash on those? That sounds all like
> servers, and I haven't yet seen a request for real pretty&fast boot
> splash for servers.
Yeah, every little helps.
And the vesafb/efifb case is valid for all of the desktop/laptop machines as well.
>> Also, where would I hook into KMS, were I to implement it on top of KMS right now? I'm not working on top of FB per se, but on top of fbcon. So in a KMS world I wouldn't work on KMS itself, but on top of... drmcon, which doesn't exist.
>
> Hm, I guess I need to double check again, but I don't get why you need
> to sit on top of a console for the boot splash. I mean I understand
> that you need to shut up the console when the boot splash is on, but
> from a quick look you're not using fbcon to render anything or
> otherwise tie into it. Where's the connection?
Fair point.
So the case you're looking at is someone who wants to have a bootsplash, yet doesn't want to have fbcon. Correct?
I agree, this is a case that is not covered with the current code. However such a generic solution would require the definition of new semantics of both fbcon and the bootsplash fighting for the same FB device - well, as long as no graphical application uses it. Urgh... It is a lot simpler to just dual-purpose fbcon, since it knows when to shut up on its own.
And I simply assume that those who load a bootsplash file into their initramfs won't be short a few bytes to compile in fbcon as well.
So... I've hooked into fbcon for simplicity's sake, so I don't have up to three parties fighting for the same device, and so I don't have to define semantics and interfaces to solve that conflict.
Max
_______________________________________________
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-19 16:23 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 [this message]
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
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=24fd8767-bdf2-0073-2161-a0cf3b61780d@suse.de \
--to=mstaudt@suse.de \
--cc=b.zolnierkie@samsung.com \
--cc=bernhard.rosenkranzer@linaro.org \
--cc=daniel@ffwll.ch \
--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).