From: Daniel Vetter <daniel@ffwll.ch>
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, philm@manjaro.org,
bernhard.rosenkranzer@linaro.org
Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing
Date: Tue, 19 Dec 2017 13:23:13 +0100 [thread overview]
Message-ID: <20171219122313.GE26573@phenom.ffwll.local> (raw)
In-Reply-To: <d66a994a-cb3a-c1fb-8f91-adbd475a40f0@suse.de>
On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
> On 12/13/2017 10:35 PM, Daniel Vetter wrote:
> > Using drm directly would allow you to flush the contents without the fake
> > (and tbh, really expensive on most drivers) copy op. If you insist on
> > using fbdev for this stuff, then at least add a new hook to flush cpu
> > rendering.
>
> My reasoning is as follows:
>
> 1) The splash screen is meant to appear as early as possible in the boot
> process, and even on devices that don't have a DRM driver. For example,
> an ARM box with only efifb. Thus, the choice to work on top of FB.
>
> 2) We need to go out of the way when a graphical application starts, and
> come back when it's done. fbcon already has the logic for this, and
> fbcon is also the thing we're trying to hide. So it seems natural to add
> the splash on top of fbcon - at least for now.
And this "automatically disappear" semantics is horribly ill-defined
between fbdev and native kms. So you're not really solving a problem,
you're just not noticing the hacks because they're one layer removed (in
the fbdev emulation code).
> 3) I can't use DRM from the kernel, for the same reason for which there
> is no "drmcon" to supplant fbcon: There is no interface to reserve
> framebuffer memory from kernel space: To get memory for a framebuffer,
> one needs to have a struct file that is passed through the DRM stack
> down into the drivers.
On recent kernels you only need a struct drm_file, not a struct file. That
can be NULL. We've done this to make drmcon possible/easier.
> If this interface existed, then there could be a generic "fb2drm"
> translation layer, and we would no longer need FB compatibility code in
> each KMS driver. Actually, I tried to implement this translation layer a
> year ago, and hit too many walls.
We're pretty much there already I think. The reason it's not entirely gone
is that there's some nasty interactions between drm and the fbdev
emulation, and just having a pile of drivers that aren't too trivial to
convert.
> I've prepared the code for a future in which fbdev no longer exists: My
> sysfs interface is generically called "bootsplash", in the hope that it
> will one day move on top of KMS. The hooks into fbcon are minimal and
> the code is straightforward to port to KMS operations rather than FB.
> But that's for another day, as far as I can see.
>
> 4) I don't fully understand what you'd like me to do. Last time I tried
> to add a new entry to the fbops struct (namely fb_open_adj_file()), you
> told me not to touch the framebuffer subsystem anymore, as it is meant
> to die and driver developers shall use KMS instead. Have I
> misunderstood?
I still don't like anyone adding features to fbdev :-)
> Something like fb->flush() to finish kernel space accesses would be nice
> to have, but would need to be implemented for all affected drivers
> separately. The copy op hack is ugly, but solves the problem
> generically.
Well, with defio being the hack it is (and because of that, a bunch of drm
drivers not really supporting it) I'm not sure things actually work better
without all this.
> What shall I do?
>
> Shall I add a new FB op for flushing when writing to the raw memory from the kernel?
> As far as I can see, it would be needed for defio drivers only, is that correct?
Yes, which are kinda horrible anyway. I guess you could at least not do
all these hacks if it's not a defio driver.
-Daniel
>
>
> >> + *
> >> + * A few DRM drivers' FB implementations are broken by not using
> >> + * deferred_io when they really should - we match on the known
> >> + * bad ones manually for now.
> >> + */
> >> + if (info->fbdefio
> >> + || !strcmp(info->fix.id, "astdrmfb")
> >> + || !strcmp(info->fix.id, "cirrusdrmfb")
> >> + || !strcmp(info->fix.id, "mgadrmfb")) {
> >
> > We have a shared defio implementation now in drm_fb_helper.c, there's not
> > really many excuses to not fix up these drivers to just use those ...
>
> I'll look into it.
>
>
> Thanks!
> Max
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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 12: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 [this message]
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
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=20171219122313.GE26573@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--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
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).