Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:

On 12/13/2017 10:35 PM, Daniel Vetter wrote:

quoted

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

quoted

quoted

+	 *
+	 * 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