Re: [RFC v3 11/12] drm/client: Add bootsplash client

[Max Staudt]

Thanks for CCing!

I like the idea of this patchset. As far as I understand, this multiplexing is 
exactly what I would have had to write in order to port the bootsplash to DRM. 
And we finally get rid of the driver-specific FB emulation hacks, too. Good 
riddance.

Thanks for the initiative, Noralf!

I've stopped working on the bootsplash since there seemed to be no more 
interest in it - but if there is, I can port it to such an in-kernel DRM client 
architecture once it's in.


Max

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Max Staudt]

Framebuffers with deferred I/O need to be flushed to the screen
explicitly, since we use neither the mmap nor the file I/O abstractions
that handle this for userspace FB clients.

Example: xenfb

Some framebuffer drivers implement lazy access to the screen without
actually exposing a fbdefio interface - we also match some known ones,
currently:
 - ast
 - cirrus
 - mgag200

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/video/fbdev/core/bootsplash.c  |  2 ++
 drivers/video/fbdev/core/bootsplash_internal.h |  1 +
 drivers/video/fbdev/core/bootsplash_render.c   | 33 ++
 3 files changed, 36 insertions(+)

diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index 843c5400fefc..815b007f81ca 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -112,6 +112,8 @@ void bootsplash_render_full(struct fb_info *info)
 
bootsplash_do_render_pictures(info, splash_state.file);
 
+   bootsplash_do_render_flush(info);
+
 out:
mutex_unlock(_state.data_lock);
 }
diff --git a/drivers/video/fbdev/core/bootsplash_internal.h 
b/drivers/video/fbdev/core/bootsplash_internal.h
index 71e2a27ac0b8..0acb383aa4e3 100644
--- a/drivers/video/fbdev/core/bootsplash_internal.h
+++ b/drivers/video/fbdev/core/bootsplash_internal.h
@@ -89,6 +89,7 @@ void bootsplash_do_render_background(struct fb_info *info,
 const struct splash_file_priv *fp);
 void bootsplash_do_render_pictures(struct fb_info *info,
   const struct splash_file_priv *fp);
+void bootsplash_do_render_flush(struct fb_info *info);
 
 
 void bootsplash_free_file(struct splash_file_priv *fp);
diff --git a/drivers/video/fbdev/core/bootsplash_render.c 
b/drivers/video/fbdev/core/bootsplash_render.c
index 2ae36949d0e3..8c09c306ff67 100644
--- a/drivers/video/fbdev/core/bootsplash_render.c
+++ b/drivers/video/fbdev/core/bootsplash_render.c
@@ -186,3 +186,36 @@ void bootsplash_do_render_pictures(struct fb_info *info,
pp->pic_header->width, pp->pic_header->height);
}
 }
+
+
+void bootsplash_do_render_flush(struct fb_info *info)
+{
+   /*
+* FB drivers using deferred_io (such as Xen) need to sync the
+* screen after modifying its contents. When the FB is mmap()ed
+* from userspace, this happens via a dirty pages callback, but
+* when modifying the FB from the kernel, there is no such thing.
+*
+* So let's issue a fake fb_copyarea (copying the FB onto itself)
+* to trick the FB driver into syncing the screen.
+*
+* 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")) {
+   struct fb_copyarea area;
+
+   area.dx = 0;
+   area.dy = 0;
+   area.width = info->var.xres;
+   area.height = info->var.yres;
+   area.sx = 0;
+   area.sy = 0;
+
+   info->fbops->fb_copyarea(info, );
+   }
+}
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v3 04/13] bootsplash: Add corner positioning

[Max Staudt]

This allows showing multiple logos, each in its own position,
relative to the eight screen corners.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 drivers/video/fbdev/core/bootsplash_render.c | 136 ++-
 include/uapi/linux/bootsplash_file.h |  45 -
 2 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/core/bootsplash_render.c 
b/drivers/video/fbdev/core/bootsplash_render.c
index 8c09c306ff67..07e3a4eab811 100644
--- a/drivers/video/fbdev/core/bootsplash_render.c
+++ b/drivers/video/fbdev/core/bootsplash_render.c
@@ -155,6 +155,7 @@ void bootsplash_do_render_pictures(struct fb_info *info,
for (i = 0; i < fp->header->num_pics; i++) {
struct splash_blob_priv *bp;
struct splash_pic_priv *pp = >pics[i];
+   const struct splash_pic_header *ph = pp->pic_header;
long dst_xoff, dst_yoff;
 
if (pp->blobs_loaded < 1)
@@ -165,8 +166,139 @@ void bootsplash_do_render_pictures(struct fb_info *info,
if (!bp || bp->blob_header->type != 0)
continue;
 
-   dst_xoff = (info->var.xres - pp->pic_header->width) / 2;
-   dst_yoff = (info->var.yres - pp->pic_header->height) / 2;
+   switch (ph->position) {
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_TOP_LEFT:
+   dst_xoff = 0;
+   dst_yoff = 0;
+
+   dst_xoff += ph->position_offset;
+   dst_yoff += ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_TOP:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = 0;
+
+   dst_yoff += ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_TOP_RIGHT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_yoff = 0;
+
+   dst_xoff -= ph->position_offset;
+   dst_yoff += ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_RIGHT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_xoff -= ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_BOTTOM_RIGHT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+
+   dst_xoff -= ph->position_offset;
+   dst_yoff -= ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_BOTTOM:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+
+   dst_yoff -= ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_BOTTOM_LEFT:
+   dst_xoff = 0 + ph->position_offset;
+   dst_yoff = info->var.yres - pp->pic_header->height
+ - ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_LEFT:
+   dst_xoff = 0;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_xoff += ph->position_offset;
+   break;
+
+   case SPLASH_CORNER_TOP_LEFT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_xoff -= ph->position_offset;
+   dst_yoff -= ph->position_offset;
+   break;
+   case SPLASH_CORNER_TOP:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_yoff -= ph->position_offset;
+   break;
+

[RFC PATCH v3 11/13] bootsplash: sysfs entries to load and unload files

[Max Staudt]

Users can use this to replace their splash screen at runtime by writing
a path and filename to /sys/devices/platform/bootsplash.0/load_file and
making sure the splash is enabled.

Notes:
  - The path has to be a path in /lib/firmware since request_firmware()
is used to fetch the data.
  - When setting the splash from the shell, echo -n has to be used as
any trailing '\n' newline will be interpreted as part of the path.

Writes to /sys/devices/platform/bootsplash.0/drop_splash will cause the
current splash theme to be freed and the console to switch to text mode,

Signed-off-by: Max Staudt <msta...@suse.de>
---
 .../ABI/testing/sysfs-platform-bootsplash  | 32 +
 Documentation/bootsplash.rst   |  8 
 drivers/video/fbdev/core/bootsplash.c  | 54 ++
 3 files changed, 94 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-platform-bootsplash 
b/Documentation/ABI/testing/sysfs-platform-bootsplash
index 742c7b035ded..f8f4b259220e 100644
--- a/Documentation/ABI/testing/sysfs-platform-bootsplash
+++ b/Documentation/ABI/testing/sysfs-platform-bootsplash
@@ -9,3 +9,35 @@ Description:
1: Splash is shown whenever fbcon would show a text console
   (i.e. no graphical application is running), and a splash
   file is loaded.
+
+What:  /sys/devices/platform/bootsplash.0/drop_splash
+Date:  Oct 2017
+KernelVersion: 4.14
+Contact:       Max Staudt <msta...@suse.de>
+Description:
+   Can only be set.
+
+   Any value written will cause the current splash theme file
+   to be unloaded and the text console to be redrawn.
+
+What:  /sys/devices/platform/bootsplash.0/load_file
+Date:  Oct 2017
+KernelVersion: 4.14
+Contact:   Max Staudt <msta...@suse.de>
+Description:
+   Can only be set.
+
+   Any value written will cause the splash to be disabled and
+   internal memory structures to be freed.
+
+   A firmware path written will cause a new theme file to be
+   loaded and the current bootsplash to be replaced.
+   The current enabled/disabled status is not touched.
+   If the splash is already active, it will be redrawn.
+
+   The path has to be a path in /lib/firmware since
+   request_firmware() is used to fetch the data.
+
+   When setting the splash from the shell, echo -n has to be
+   used as any trailing '\n' newline will be interpreted as
+   part of the path.
diff --git a/Documentation/bootsplash.rst b/Documentation/bootsplash.rst
index 611f0c558925..b35aba5093e8 100644
--- a/Documentation/bootsplash.rst
+++ b/Documentation/bootsplash.rst
@@ -67,6 +67,14 @@ sysfs run-time configuration
   a splash theme file is also loaded.
 
 
+``/sys/devices/platform/bootsplash.0/drop_splash``
+  Unload splash data and free memory.
+
+``/sys/devices/platform/bootsplash.0/load_file``
+  Load a splash file from ``/lib/firmware/``.
+  Note that trailing newlines will be interpreted as part of the file name.
+
+
 
 Kconfig
 ===
diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index 13fcaabbc2ca..16cb0493629d 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -251,11 +251,65 @@ static ssize_t splash_store_enabled(struct device *device,
return count;
 }
 
+static ssize_t splash_store_drop_splash(struct device *device,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct splash_file_priv *fp;
+
+   if (!buf || !count || !splash_state.file)
+   return count;
+
+   mutex_lock(_state.data_lock);
+   fp = splash_state.file;
+   splash_state.file = NULL;
+   mutex_unlock(_state.data_lock);
+
+   /* Redraw the text console */
+   schedule_work(_state.work_redraw_vc);
+
+   bootsplash_free_file(fp);
+
+   return count;
+}
+
+static ssize_t splash_store_load_file(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   struct splash_file_priv *fp, *fp_old;
+
+   if (!count)
+   return 0;
+
+   fp = bootsplash_load_firmware(_state.splash_device->dev,
+ buf);
+
+   if (!fp)
+   return -ENXIO;
+
+   mutex_lock(_state.data_lock);
+   fp_old = splash_state.file;
+   splash_state.splash_fb = NULL;
+   splash_state.file = fp;
+   mutex_unlock(_state.data_lock);
+
+   /* Update the splash or text console */
+   schedule_work(_state.work_redraw_vc);
+
+   bootsplash_free_file(fp_old);
+   return count;
+}
+
 stati

[RFC PATCH v3 02/13] bootsplash: Add file reading and picture rendering

[Max Staudt]

Load logo(s) from a file and render them in the center of the screen.

This removes the "black screen" functionality, which can now be emulated
by providing a splash file with no pictures and a black background.

To enable the bootsplash at boot, provide a theme file *in the initramfs*
and tell the kernel to use it as follows:

  bootsplash.bootfile=mypath/myfile

Since the splash code is using request_firmware() to load the file,
the path has to be beneath /lib/firmware.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 MAINTAINERS|   1 +
 drivers/video/fbdev/core/Makefile  |   2 +-
 drivers/video/fbdev/core/bootsplash.c  |  36 +++-
 drivers/video/fbdev/core/bootsplash_internal.h |  45 -
 drivers/video/fbdev/core/bootsplash_load.c | 225 +
 drivers/video/fbdev/core/bootsplash_render.c   | 103 ++-
 include/uapi/linux/bootsplash_file.h   | 118 +
 7 files changed, 522 insertions(+), 8 deletions(-)
 create mode 100644 drivers/video/fbdev/core/bootsplash_load.c
 create mode 100644 include/uapi/linux/bootsplash_file.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b5633b56391e..5c237445761e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2712,6 +2712,7 @@ S:Maintained
 F: drivers/video/fbdev/core/bootsplash*.*
 F: drivers/video/fbdev/core/dummycon.c
 F: include/linux/bootsplash.h
+F: include/uapi/linux/bootsplash_file.h
 
 BPF (Safe dynamic programs and tools)
 M: Alexei Starovoitov <a...@kernel.org>
diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
index 66895321928e..6a8d1bab8a01 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -31,4 +31,4 @@ obj-$(CONFIG_FB_SVGALIB)   += svgalib.o
 obj-$(CONFIG_FB_DDC)   += fb_ddc.o
 
 obj-$(CONFIG_BOOTSPLASH)   += bootsplash.o bootsplash_render.o \
-  dummyblit.o
+  bootsplash_load.o dummyblit.o
diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index e449755af268..843c5400fefc 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -32,6 +32,7 @@
 #include 
 
 #include "bootsplash_internal.h"
+#include "uapi/linux/bootsplash_file.h"
 
 
 /*
@@ -102,10 +103,17 @@ static bool is_fb_compatible(const struct fb_info *info)
  */
 void bootsplash_render_full(struct fb_info *info)
 {
+   mutex_lock(_state.data_lock);
+
if (!is_fb_compatible(info))
-   return;
+   goto out;
+
+   bootsplash_do_render_background(info, splash_state.file);
+
+   bootsplash_do_render_pictures(info, splash_state.file);
 
-   bootsplash_do_render_background(info);
+out:
+   mutex_unlock(_state.data_lock);
 }
 
 
@@ -116,6 +124,7 @@ bool bootsplash_would_render_now(void)
 {
return !oops_in_progress
&& !console_blanked
+   && splash_state.file
&& bootsplash_is_enabled();
 }
 
@@ -252,6 +261,7 @@ static struct platform_driver splash_driver = {
 void bootsplash_init(void)
 {
int ret;
+   struct splash_file_priv *fp;
 
/* Initialized already? */
if (splash_state.splash_device)
@@ -280,8 +290,26 @@ void bootsplash_init(void)
}
 
 
+   mutex_init(_state.data_lock);
+   set_bit(0, _state.enabled);
+
INIT_WORK(_state.work_redraw_vc, splash_callback_redraw_vc);
 
+
+   if (!splash_state.bootfile || !strlen(splash_state.bootfile))
+   return;
+
+   fp = bootsplash_load_firmware(_state.splash_device->dev,
+ splash_state.bootfile);
+
+   if (!fp)
+   goto err;
+
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   splash_state.file = fp;
+   mutex_unlock(_state.data_lock);
+
return;
 
 err_device:
@@ -292,3 +320,7 @@ void bootsplash_init(void)
 err:
pr_err("Failed to initialize.\n");
 }
+
+
+module_param_named(bootfile, splash_state.bootfile, charp, 0444);
+MODULE_PARM_DESC(bootfile, "Bootsplash file to load on boot");
diff --git a/drivers/video/fbdev/core/bootsplash_internal.h 
b/drivers/video/fbdev/core/bootsplash_internal.h
index b11da5cb90bf..71e2a27ac0b8 100644
--- a/drivers/video/fbdev/core/bootsplash_internal.h
+++ b/drivers/video/fbdev/core/bootsplash_internal.h
@@ -15,15 +15,43 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include "uapi/linux/bootsplash_file.h"
+
 
 /*
  * Runtime types
  */
+struct splash_blob_priv {
+   struct splash_blob_header *blob_header;
+   const void *data;
+};
+
+
+struct splash_pic_priv {
+   const struct splash_pic_header *pic_header;
+
+   struct splash_blob_priv *blobs;
+   u16 blobs

[RFC PATCH v3 13/13] tools/bootsplash: Add script and data to create sample file

[Max Staudt]

Also, mention this in the bootsplash documentation.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 Documentation/bootsplash.rst   |  10 ++
 tools/bootsplash/.gitignore|   3 ++
 tools/bootsplash/ajax-loader.gif   | Bin 0 -> 3208 bytes
 tools/bootsplash/bootsplash-tux.sh |  66 +
 4 files changed, 79 insertions(+)
 create mode 100644 tools/bootsplash/ajax-loader.gif
 create mode 100755 tools/bootsplash/bootsplash-tux.sh

diff --git a/Documentation/bootsplash.rst b/Documentation/bootsplash.rst
index b35aba5093e8..d4f132eca615 100644
--- a/Documentation/bootsplash.rst
+++ b/Documentation/bootsplash.rst
@@ -195,6 +195,16 @@ Hooks - how the bootsplash is integrated
 
 
 
+Crating a bootsplash theme file
+===
+
+A simple tool for theme file creation is included in ``tools/bootsplash``.
+
+There is also an example shell script, as an example on how to use the tool
+and in order to generate a reference bootsplash file.
+
+
+
 FAQ: Frequently Asked Questions
 ===
 
diff --git a/tools/bootsplash/.gitignore b/tools/bootsplash/.gitignore
index 091b99a17567..5dfced41ba82 100644
--- a/tools/bootsplash/.gitignore
+++ b/tools/bootsplash/.gitignore
@@ -1 +1,4 @@
 bootsplash-packer
+bootsplash
+logo.rgb
+throbber*.rgb
diff --git a/tools/bootsplash/ajax-loader.gif b/tools/bootsplash/ajax-loader.gif
new file mode 100644
index 
..3288d1035d70bb86517e2c233f1a904e41f06b29
GIT binary patch
literal 3208
zcmc(iX;4#H9>pJdFE7h`I{IF)0|5<6L}(j=N}5%L009EB2nYfyF)E0PvIqo$u!IC;
z4PgyY5|S9AEh38G)(9eq4TbH7_UHg@yWrlIJ$6smIADL7s^P;_O;ykRc<bJ}b9soXl`UC*LwQJXkii*0rx|*7rI2=x7WaRkx_~XZqFJ8R3c=2Kg
zf@aSAv8+BJ8+^hyay>(QR@t*blbKzsf0}bscEqRc5Hd3o(-N5RyW=zWB*zQw6Zh>*
z2CROCDAbu#D`)S|J_<lj7Yz9)#_Og>o(lL9Yn3l*+8RdiRD_>iNz$#_IAzCna
zSF_(rRCDD!wi#i8oAm_@VB%2-H*G%bN#|(6R6N?wM)3u`PiGzwuX7qmTgyF
zpE)h0kuoxQ9?=kW7Y!=R@DmhU9)vwT<ZMc0Y;%TT3z!|H=R-GXDHPiKcVWh
zY+!etO=DI2rIs8{iFWtPv(Lu|O3u|$F3Sbq;+xF{gTX$#T%m?MUUZy$=zXgXj
zrxrf}reg*D3HB~8JyLgl$UCyV?EQ`@OKjW@tGrvh6ZqPD#+m=rK0T{FT01>*EZWzJ
zrt+=2tqFts72yIp?|gvdLhs8Hfku^Z(){gmN%Y=K#<L1VKWYjwV^JDyeS;Y$p1xw*
z#3VzfAV>P|%fkvg

[RFC PATCH v3 05/13] bootsplash: Add animation support

[Max Staudt]

Each 'picture' in the splash file can consist of multiple 'blobs'.

If animation is enabled, these blobs become the frames of an animation,
in the order in which they are stored in the file.

Note: There is only one global timer, so all animations happen at
  the same frame rate. It doesn't really make sense to animate
  more than one object at a time anyway.

Furthermore, this patch introduces a check for reusing a framebuffer
where the splash has recently been painted on - in this case, we only
redraw the objects that are animated.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 drivers/video/fbdev/core/bootsplash.c  | 62 +++---
 drivers/video/fbdev/core/bootsplash_internal.h | 13 +-
 drivers/video/fbdev/core/bootsplash_load.c | 21 +
 drivers/video/fbdev/core/bootsplash_render.c   | 30 -
 include/uapi/linux/bootsplash_file.h   | 35 ++-
 5 files changed, 151 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index 815b007f81ca..c8642142cfea 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -53,6 +53,14 @@ static void splash_callback_redraw_vc(struct work_struct 
*ignored)
console_unlock();
 }
 
+static void splash_callback_animation(struct work_struct *ignored)
+{
+   if (bootsplash_would_render_now()) {
+   /* This will also re-schedule this delayed worker */
+   splash_callback_redraw_vc(ignored);
+   }
+}
+
 
 static bool is_fb_compatible(const struct fb_info *info)
 {
@@ -103,17 +111,44 @@ static bool is_fb_compatible(const struct fb_info *info)
  */
 void bootsplash_render_full(struct fb_info *info)
 {
+   bool is_update = false;
+
mutex_lock(_state.data_lock);
 
-   if (!is_fb_compatible(info))
-   goto out;
+   /*
+* If we've painted on this FB recently, we don't have to do
+* the sanity checks and background drawing again.
+*/
+   if (splash_state.splash_fb == info)
+   is_update = true;
+
+
+   if (!is_update) {
+   /* Check whether we actually support this FB. */
+   splash_state.splash_fb = NULL;
+
+   if (!is_fb_compatible(info))
+   goto out;
+
+   /* Draw the background only once */
+   bootsplash_do_render_background(info, splash_state.file);
 
-   bootsplash_do_render_background(info, splash_state.file);
+   /* Mark this FB as last seen */
+   splash_state.splash_fb = info;
+   }
 
-   bootsplash_do_render_pictures(info, splash_state.file);
+   bootsplash_do_render_pictures(info, splash_state.file, is_update);
 
bootsplash_do_render_flush(info);
 
+   bootsplash_do_step_animations(splash_state.file);
+
+   /* Schedule update for animated splash screens */
+   if (splash_state.file->frame_ms > 0)
+   schedule_delayed_work(_state.dwork_animation,
+ msecs_to_jiffies(
+ splash_state.file->frame_ms));
+
 out:
mutex_unlock(_state.data_lock);
 }
@@ -169,8 +204,14 @@ void bootsplash_enable(void)
 
was_enabled = test_and_set_bit(0, _state.enabled);
 
-   if (!was_enabled)
+   if (!was_enabled) {
+   /* Force a full redraw when the splash is re-activated */
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   mutex_unlock(_state.data_lock);
+
schedule_work(_state.work_redraw_vc);
+   }
 }
 
 
@@ -227,6 +268,14 @@ ATTRIBUTE_GROUPS(splash_dev);
  */
 static int splash_resume(struct device *device)
 {
+   /*
+* Force full redraw on resume since we've probably lost the
+* framebuffer's contents meanwhile
+*/
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   mutex_unlock(_state.data_lock);
+
if (bootsplash_would_render_now())
schedule_work(_state.work_redraw_vc);
 
@@ -235,6 +284,7 @@ static int splash_resume(struct device *device)
 
 static int splash_suspend(struct device *device)
 {
+   cancel_delayed_work_sync(_state.dwork_animation);
cancel_work_sync(_state.work_redraw_vc);
 
return 0;
@@ -296,6 +346,8 @@ void bootsplash_init(void)
set_bit(0, _state.enabled);
 
INIT_WORK(_state.work_redraw_vc, splash_callback_redraw_vc);
+   INIT_DELAYED_WORK(_state.dwork_animation,
+ splash_callback_animation);
 
 
if (!splash_state.bootfile || !strlen(splash_state.bootfile))
diff --git a/drivers/video/fbdev/core/bootsplash_internal.h 
b/drivers/video/fbdev/core/bootsplash_internal.h
index 0acb383aa4e3..b3a74835d90f 100644
--- a/drivers/video/fbdev/core/bootsplash_internal.h
+++ b/drivers/v

[RFC PATCH v3 10/13] Documentation: Add bootsplash main documentation

[Max Staudt]

Signed-off-by: Max Staudt <msta...@suse.de>
---
 .../ABI/testing/sysfs-platform-bootsplash  |  11 +
 Documentation/bootsplash.rst   | 285 +
 MAINTAINERS|   2 +
 3 files changed, 298 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-bootsplash
 create mode 100644 Documentation/bootsplash.rst

diff --git a/Documentation/ABI/testing/sysfs-platform-bootsplash 
b/Documentation/ABI/testing/sysfs-platform-bootsplash
new file mode 100644
index ..742c7b035ded
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-bootsplash
@@ -0,0 +1,11 @@
+What:  /sys/devices/platform/bootsplash.0/enabled
+Date:  Oct 2017
+KernelVersion: 4.14
+Contact:       Max Staudt <msta...@suse.de>
+Description:
+   Can be set and read.
+
+   0: Splash is disabled.
+   1: Splash is shown whenever fbcon would show a text console
+  (i.e. no graphical application is running), and a splash
+  file is loaded.
diff --git a/Documentation/bootsplash.rst b/Documentation/bootsplash.rst
new file mode 100644
index ..611f0c558925
--- /dev/null
+++ b/Documentation/bootsplash.rst
@@ -0,0 +1,285 @@
+
+The Linux bootsplash
+
+
+:Date: November, 2017
+:Author: Max Staudt <msta...@suse.de>
+
+
+The Linux bootsplash is a graphical replacement for the '``quiet``' boot
+option, typically showing a logo and a spinner animation as the system starts.
+
+Currently, it is a part of the Framebuffer Console support, and can be found
+as ``CONFIG_BOOTSPLASH`` in the kernel configuration. This means that as long
+as it is enabled, it hijacks fbcon's output and draws a splash screen instead.
+
+Purely compiling in the bootsplash will not render it functional - to actually
+render a splash, you will also need a splash theme file. See the example
+utility and script in ``tools/bootsplash`` for a live demo.
+
+
+
+Motivation
+==
+
+- The '``quiet``' boot option only suppresses most messages during boot, but
+  errors are still shown.
+
+- A user space implementation can only show a logo once user space has been
+  initialized far enough to allow this. A kernel splash can display a splash
+  immediately as soon as fbcon can be displayed.
+
+- Implementing a splash screen in user space (e.g. Plymouth) is problematic
+  due to resource conflicts.
+
+  For example, if Plymouth is keeping ``/dev/fb0`` (provided via vesafb/efifb)
+  open, then most DRM drivers can't replace it because the address space is
+  still busy - thus leading to a VRAM reservation error.
+
+  See: https://bugzilla.opensuse.org/show_bug.cgi?id=980750
+
+
+
+Command line arguments
+==
+
+``bootsplash.bootfile``
+  Which file in the initramfs to load.
+
+  The splash theme is loaded via request_firmware(), thus to load
+  ``/lib/firmware/bootsplash/mytheme`` pass the command line:
+
+  ``bootsplash.bootfile=bootsplash/mytheme``
+
+  Note: The splash file *has to be* in the initramfs, as it needs to be
+  available when the splash is initialized early on.
+
+  Default: none, i.e. a non-functional splash, falling back to showing text.
+
+
+
+sysfs run-time configuration
+
+
+``/sys/devices/platform/bootsplash.0/enabled``
+  Enable/disable the bootsplash.
+  The system boots with this set to 1, but will not show a splash unless
+  a splash theme file is also loaded.
+
+
+
+Kconfig
+===
+
+``BOOTSPLASH``
+  Whether to compile in bootsplash support
+  (depends on fbcon compiled in, i.e. ``FRAMEBUFFER_CONSOLE=y``)
+
+
+
+Bootsplash file format
+==
+
+A file specified in the kernel configuration as ``CONFIG_BOOTSPLASH_FILE``
+or specified on the command line as ``bootsplash.bootfile`` will be loaded
+and displayed as soon as fbcon is initialized.
+
+
+Main blocks
+---
+
+There are 3 main blocks in each file:
+
+  - one File header
+  -   n Picture headers
+  -   m (Blob header + payload) blocks
+
+
+Structures
+--
+
+The on-disk structures are defined in
+``drivers/video/fbdev/core/bootsplash_file.h`` and represent these blocks:
+
+  - ``struct splash_file_header``
+
+Represents the file header, with splash-wide information including:
+
+  - The magic string "``Linux bootsplash``" on big-endian platforms
+(the reverse on little endian)
+  - The file format version (for incompatible updates, hopefully never)
+  - The background color
+  - Number of picture and blob blocks
+  - Animation speed (we only allow one delay for all animations)
+
+The file header is followed by the first picture header.
+
+
+  - ``struct splash_picture_header``
+
+Represents an object (picture) drawn on screen, including its immutable
+properties:
+  - Width, height
+  - Positioning relative to scr

[RFC PATCH v3 00/13] Kernel based bootsplash

[Max Staudt]

Dear fbdev/fbcon/dri developers,

Thanks for all the valuable feedback.

I've looked into the suggestions you made, and found that it doesn't
currently make sense to continue working on the splash code, given the
low practical interest I've received on LKML. The code is, and always
has been, intended primarily as a study of what can be done, and at
this point it has fulfilled this requirement.

Please find attached my latest version of the patchset in which I've
clarified the documentation a bit, as well as added a FAQ and To-Do
section for anyone wishing to pick up the code.

The code is still based on v4.14-rc5, sorry about that.

In particular, I hope to have clarified in the FAQ why I'm building on
top of fbdev and fbcon, as I think I haven't made myself clear enough
in the previous discussion. If you still think that my reasoning is
wrong, I'd be thankful for pointers towards a better solution.


I'll be happy to rebase it and continue to work on it if interest
arises.


This project has been a valuable experience - so huge thanks to everyone
involved in any way, from user feedback over code reviews and all the way
to architectural discussion.


Max


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v3 01/13] bootsplash: Initial implementation showing black screen

[Max Staudt]

This is the initial prototype for a lean Linux kernel bootsplash.

It works by replacing fbcon's FB manipulation routines (such as
bitblit, tileblit) with dummy functions, effectively disabling text
output, and drawing the splash directly onto the FB device.

There is a userland API via sysfs, to show/hide the splash on request
by dracut, systemd, or other init systems.

As of this commit, the code will show a black screen rather than a
logo, and only if manually enabled via sysfs by writing:

  echo 1 > /sys/devices/platform/bootsplash.0/enabled

The reasons for implementing a bootsplash in kernel space are:

 - Quieting things more and nicer than with the quiet boot option:
   Currently the 'quiet' boot option does not remove the blinking
   cursor and errors are still printed. There are use cases where this
   is not desirable (such as embedded and desktop systems, digital
   signage, etc.) and a vendor logo is preferable.

 - Showing graphics, and never text, when the GUI crashes:
   This is an extension of the above use case, where recovery is meant
   to happen as invisibly to the user as possible. A system integrator
   needs the flexibility to hide "scary text" from users in all cases
   other than a panic.
   This is especially desirable in embedded systems such as digital
   signage.

 - Racy VT API:
   Userspace bootsplashes and GUIs (e.g. plymouth and X) tend to kick
   each other out via the non-exclusive KDSETMODE ioctl. This can
   result in situations such as the user being stuck in X with chvt
   and Ctrl-Alt-Fx no longer working.

 - Mode switching from FB to KMS:
   We cannot switch from a generic framebuffer (vesafb, efifb) to a
   KMS driver while a userspace splash keeps /dev/fb0 open. The device
   will vanish, but the address space is still busy, so the KMS driver
   cannot reserve its VRAM.

 - Simplification of userspace integration:
   Right now, hooking up a splash screen in userspace is quite complex.
   Having it in the kernel makes this a breeze, as hooks for
   switch_root, remounting r/w, etc. become obsolete.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 MAINTAINERS|   8 +
 drivers/video/console/Kconfig  |  24 ++
 drivers/video/fbdev/core/Makefile  |   3 +
 drivers/video/fbdev/core/bootsplash.c  | 294 +
 drivers/video/fbdev/core/bootsplash_internal.h |  55 +
 drivers/video/fbdev/core/bootsplash_render.c   |  93 
 drivers/video/fbdev/core/dummyblit.c   |  89 
 drivers/video/fbdev/core/fbcon.c   |  22 ++
 drivers/video/fbdev/core/fbcon.h   |   5 +
 include/linux/bootsplash.h |  43 
 10 files changed, 636 insertions(+)
 create mode 100644 drivers/video/fbdev/core/bootsplash.c
 create mode 100644 drivers/video/fbdev/core/bootsplash_internal.h
 create mode 100644 drivers/video/fbdev/core/bootsplash_render.c
 create mode 100644 drivers/video/fbdev/core/dummyblit.c
 create mode 100644 include/linux/bootsplash.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a74227ad082e..b5633b56391e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2705,6 +2705,14 @@ S:   Supported
 F: drivers/net/bonding/
 F: include/uapi/linux/if_bonding.h
 
+BOOTSPLASH
+M: Max Staudt <msta...@suse.de>
+L: linux-fb...@vger.kernel.org
+S: Maintained
+F: drivers/video/fbdev/core/bootsplash*.*
+F: drivers/video/fbdev/core/dummycon.c
+F: include/linux/bootsplash.h
+
 BPF (Safe dynamic programs and tools)
 M: Alexei Starovoitov <a...@kernel.org>
 M: Daniel Borkmann <dan...@iogearbox.net>
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..f3ff976266fe 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -151,6 +151,30 @@ config FRAMEBUFFER_CONSOLE_ROTATION
  such that other users of the framebuffer will remain normally
  oriented.
 
+config BOOTSPLASH
+   bool "Bootup splash screen"
+   depends on FRAMEBUFFER_CONSOLE
+   ---help---
+ This option enables the Linux bootsplash screen.
+
+ The bootsplash is a full-screen logo or animation indicating a
+ booting system. It replaces the classic scrolling text with a
+ graphical alternative, similar to other systems.
+
+ Since this is technically implemented as a hook on top of fbcon,
+ it can only work if the FRAMEBUFFER_CONSOLE is enabled and a
+ framebuffer driver is active. Thus, to get a text-free boot,
+ the system needs to boot with vesafb, efifb, or similar.
+
+ Once built into the kernel, the bootsplash needs to be enabled
+ with bootsplash.enabled=1 and a splash file needs to be supplied.
+
+ Further documentation can be found in:
+   Documentation/fb/bootsplash.txt
+
+ If unsure, say N.
+ Th

[RFC PATCH v3 08/13] sysrq: Disable bootsplash on SAK

[Max Staudt]

When the user requests a clean TTY via the SAK SysRq, that means he
really wants to use the console.

Let's disable the bootsplash, even if the request is not on a VT, as
the user probably knows what he's doing and it's more helpful to get
out of his way.

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/tty/sysrq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 3ffc1ce29023..bc6a24c9dfa8 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -104,6 +105,8 @@ static void sysrq_handle_SAK(int key)
 {
struct work_struct *SAK_work = _cons[fg_console].SAK_work;
schedule_work(SAK_work);
+
+   bootsplash_disable();
 }
 static struct sysrq_key_op sysrq_SAK_op = {
.handler= sysrq_handle_SAK,
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v3 06/13] vt: Redraw bootsplash fully on console_unblank

[Max Staudt]

After exiting a KD_GRAPHICS program and falling back to the text
console, a previously enabled splash needs to be fully redrawn.

This corner case was introduced with selective re-drawing while
implementing animations.

Without this patch, the following happens:

1. Switch to a text console
2. Enable splash
3. Start X (or any other KD_GRAPHICS program)
4. Exit X
5. Splash is not seen, apart from animations

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/tty/vt/vt.c   |  2 ++
 drivers/video/fbdev/core/bootsplash.c | 15 +--
 include/linux/bootsplash.h|  4 
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2ebaba16f785..416735ab6dc1 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -102,6 +102,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_NR_CON_DRIVER 16
 
@@ -3903,6 +3904,7 @@ void do_unblank_screen(int leaving_gfx)
}
 
console_blanked = 0;
+   bootsplash_mark_dirty();
if (vc->vc_sw->con_blank(vc, 0, leaving_gfx) || 
vt_force_oops_output(vc))
/* Low-level driver cannot restore -> do it ourselves */
update_screen(vc);
diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index c8642142cfea..13fcaabbc2ca 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -165,6 +165,13 @@ bool bootsplash_would_render_now(void)
&& bootsplash_is_enabled();
 }
 
+void bootsplash_mark_dirty(void)
+{
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   mutex_unlock(_state.data_lock);
+}
+
 bool bootsplash_is_enabled(void)
 {
bool was_enabled;
@@ -206,9 +213,7 @@ void bootsplash_enable(void)
 
if (!was_enabled) {
/* Force a full redraw when the splash is re-activated */
-   mutex_lock(_state.data_lock);
-   splash_state.splash_fb = NULL;
-   mutex_unlock(_state.data_lock);
+   bootsplash_mark_dirty();
 
schedule_work(_state.work_redraw_vc);
}
@@ -272,9 +277,7 @@ static int splash_resume(struct device *device)
 * Force full redraw on resume since we've probably lost the
 * framebuffer's contents meanwhile
 */
-   mutex_lock(_state.data_lock);
-   splash_state.splash_fb = NULL;
-   mutex_unlock(_state.data_lock);
+   bootsplash_mark_dirty();
 
if (bootsplash_would_render_now())
schedule_work(_state.work_redraw_vc);
diff --git a/include/linux/bootsplash.h b/include/linux/bootsplash.h
index c6dd0b43180d..4075098aaadd 100644
--- a/include/linux/bootsplash.h
+++ b/include/linux/bootsplash.h
@@ -19,6 +19,8 @@ extern void bootsplash_render_full(struct fb_info *info);
 
 extern bool bootsplash_would_render_now(void);
 
+extern void bootsplash_mark_dirty(void);
+
 extern bool bootsplash_is_enabled(void);
 extern void bootsplash_disable(void);
 extern void bootsplash_enable(void);
@@ -31,6 +33,8 @@ extern void bootsplash_init(void);
 
 #define bootsplash_would_render_now() (false)
 
+#define bootsplash_mark_dirty()
+
 #define bootsplash_is_enabled() (false)
 #define bootsplash_disable()
 #define bootsplash_enable()
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v3 09/13] fbcon: Disable bootsplash on oops

[Max Staudt]

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/video/fbdev/core/fbcon.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 9a39a6fcfe98..8a9c67e1c5d8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1343,6 +1343,16 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
int y;
int c = scr_readw((u16 *) vc->vc_pos);
 
+   /*
+* Disable the splash here so we don't have to hook into
+* vt_console_print() in drivers/tty/vt/vt.c
+*
+* We'd disable the splash just before the call to
+* hide_cursor() anyway, so this spot is just fine.
+*/
+   if (oops_in_progress)
+   bootsplash_disable();
+
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
 
if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1)
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v3 07/13] vt: Add keyboard hook to disable bootsplash

[Max Staudt]

Let's disable the splash if the user presses ESC or F1-F12 on a VT.

The F1-F12 check is to disable the splash on VT switches.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 drivers/tty/vt/keyboard.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index f4166263bb3a..a248429194bb 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -47,6 +47,8 @@
 
 #include 
 
+#include 
+
 extern void ctrl_alt_del(void);
 
 /*
@@ -1353,6 +1355,28 @@ static void kbd_keycode(unsigned int keycode, int down, 
int hw_raw)
}
 #endif
 
+   /* Trap keys when bootsplash is shown */
+   if (bootsplash_would_render_now()) {
+   /* Deactivate bootsplash on ESC or Alt+Fxx VT switch */
+   if (keycode >= KEY_F1 && keycode <= KEY_F12) {
+   bootsplash_disable();
+
+   /*
+* No return here since we want to actually
+* perform the VT switch.
+*/
+   } else {
+   if (keycode == KEY_ESC)
+   bootsplash_disable();
+
+   /*
+* Just drop any other keys.
+* Their effect would be hidden by the splash.
+*/
+   return;
+   }
+   }
+
if (kbd->kbdmode == VC_MEDIUMRAW) {
/*
 * This is extended medium raw mode, with keys above 127
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v3 12/13] tools/bootsplash: Add a basic splash file creation tool

[Max Staudt]

Signed-off-by: Max Staudt <msta...@suse.de>
---
 MAINTAINERS  |   1 +
 tools/bootsplash/.gitignore  |   1 +
 tools/bootsplash/Makefile|   9 +
 tools/bootsplash/bootsplash-packer.c | 471 +++
 4 files changed, 482 insertions(+)
 create mode 100644 tools/bootsplash/.gitignore
 create mode 100644 tools/bootsplash/Makefile
 create mode 100644 tools/bootsplash/bootsplash-packer.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7ffac272434e..ddff07cd794c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2715,6 +2715,7 @@ F:drivers/video/fbdev/core/bootsplash*.*
 F: drivers/video/fbdev/core/dummycon.c
 F: include/linux/bootsplash.h
 F: include/uapi/linux/bootsplash_file.h
+F: tools/bootsplash/*
 
 BPF (Safe dynamic programs and tools)
 M: Alexei Starovoitov <a...@kernel.org>
diff --git a/tools/bootsplash/.gitignore b/tools/bootsplash/.gitignore
new file mode 100644
index ..091b99a17567
--- /dev/null
+++ b/tools/bootsplash/.gitignore
@@ -0,0 +1 @@
+bootsplash-packer
diff --git a/tools/bootsplash/Makefile b/tools/bootsplash/Makefile
new file mode 100644
index ..0ad8e8a84942
--- /dev/null
+++ b/tools/bootsplash/Makefile
@@ -0,0 +1,9 @@
+CC := $(CROSS_COMPILE)gcc
+CFLAGS := -I../../usr/include
+
+PROGS := bootsplash-packer
+
+all: $(PROGS)
+
+clean:
+   rm -fr $(PROGS)
diff --git a/tools/bootsplash/bootsplash-packer.c 
b/tools/bootsplash/bootsplash-packer.c
new file mode 100644
index ..ffb6a8b69885
--- /dev/null
+++ b/tools/bootsplash/bootsplash-packer.c
@@ -0,0 +1,471 @@
+/*
+ * Kernel based bootsplash.
+ *
+ * (Splash file packer tool)
+ *
+ * Authors:
+ * Max Staudt <msta...@suse.de>
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+
+static void print_help(char *progname)
+{
+   printf("Usage: %s [OPTIONS] outfile\n", progname);
+   printf("\n"
+  "Options, executed in order given:\n"
+  "  -h, --help   Print this help message\n"
+  "\n"
+  "  --bg_red Background color (red part)\n"
+  "  --bg_green   Background color (green part)\n"
+  "  --bg_blueBackground color (blue part)\n"
+  "  --bg_reserved(do not use)\n"
+  "  --frame_ms  Minimum milliseconds between 
animation steps\n"
+  "\n"
+  "  --pictureStart describing the next 
picture\n"
+  "  --pic_width Picture width in pixels\n"
+  "  --pic_heightPicture height in pixels\n"
+  "  --pic_position  Coarse picture placement:\n"
+  "  0x00 - Top left\n"
+  "  0x01 - Top\n"
+  "  0x02 - Top right\n"
+  "  0x03 - Right\n"
+  "  0x04 - Bottom right\n"
+  "  0x05 - Bottom\n"
+  "  0x06 - Bottom left\n"
+  "  0x07 - Left\n"
+  "\n"
+  "Flags:\n"
+  " 0x10 - Calculate offset from 
corner towards center,\n"
+  " rather than from 
center towards corner\n"
+  "  --pic_position_offset   Distance from base position in 
pixels\n"
+  "  --pic_anim_type  Animation type:\n"
+  " 0 - None\n"
+  " 1 - Forward loop\n"
+  "  --pic_anim_loop  Loop point for animation\n"
+  "\n"
+  "  --blob Include next data stream\n"
+  "  --blob_type Type of data\n"
+  "  --blob_picture_idPicture to associate this blob 
with, starting at 0\n"
+  " (default: number of last 
--picture)\n"
+  "\n");
+   printf("This tool will write %s files.\n\n",
+#if __BYTE_ORDER == __BIG_ENDIAN
+  "Big Endian (BE)");
+#elif __BYTE_ORDER == __LITTLE_ENDIAN
+  "Little Endian (LE)");
+#else

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

[Max Staudt]

On 12/31/2017 01:53 PM, Alan Cox wrote:
> On Tue, 19 Dec 2017 15:07:53 +0100
> Oliver Neukum  wrote:
> 
>> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
 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).  
>>
>> Hi,
>>
>> those would be at a minimum efifb, vesafb, xenfb
>> Those are obviously not sexy, but from a practical point of view
>> they are the minimum you need to support.
> 
> I think it's more constructive to look at it the other way around. What
> drivers do we have that actually need to be used which don't have DRM
> equivalents - and how do we fix that instead ?
It's *at least* the above named drivers: efifb, vesafb, xenfb.


Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/31/2017 01:44 PM, Alan Cox wrote:
>> 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.

Oh no. Thanks for the input, that changes my perspective a bit.

So unless we could show it quickly enough, the kernel splash would be useful 
either as an addition on top of the bootloader's splash, or really aimed at 
fatter distros which wish to use something simple and kernel based.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/31/2017 01:35 PM, Alan Cox wrote:
> For embedded every KB counts. That is likely to remain the same for some
> time because at the end of the day small devices are constrained about the
> amount of SRAM you can put on die and the amount of power you can afford
> for DRAM. 

Fascinating, thanks for the insight!

Now I have a really good reason to separate the splash from fbcon.


>>> 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.
> 
> It's a total mess (the fbcon layer loading and locking that is). Doing all
> this extra kernel stuff is like sitting in a hole and instead of trying to
> climb out digging the hole bigger so you've got more room to sit in it.
I'm not sure what exactly you're unhappy about - are you complaining about the 
kernel hack in KMS drivers which allows them to kick out vesafb/efifb?



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/29/2017 06:13 PM, Jani Nikula wrote:
> I think the first issue is the boot manager (e.g. grub) messing up
> whatever the BIOS or GOP or whatever drew. If I don't touch any buttons,
> I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC
> some BIOSes let you set up your own splash if you like, though that's
> not really relevant for me. So already the boot manager takeover is a
> problem.
> 
> The next issue is the framebuffer driver takeover. It's not unlike the
> above, just one step further. If you like your grub image to stay there,
> let it stay there. (Or, if the boot manager was nice enough to not mess
> up the screen, let the BIOS image stay there.) All the way to KMS and
> userspace.
> 
> IMHO the user friendly experience is already gone by the time we reach
> any kernel/userspace bootsplash. We want our command-line tools to STFU
> if they don't have anything interesting to say. As a user, 99.99+% of
> the time I don't care what grub or dmesg have to say.

Agreed - the kernel should go out of the user's way if they want it to be 
silent. It's already possible, as long as KMS is not in use (since that 
automatically sets a mode and thus usually clears the screen).

What you want is really the opposite of the kernel splash, or any splash on top 
of Linux (kernel or userspace) at all.

Returning to cases where a splash running on Linux may be desired:
I see adding to the initial logo as an interesting use case. An animation to 
show that the kernel hasn't crashed while booting is quite useful. Something 
like adding a spinning wheel underneath the initial logo helps. Macs do (or 
used to do) that after showing the apple, IIRC. I think this is where something 
simple and kernel based is helpful, vs. something userspace based. Maybe they 
can even build on top of each other, just like LILO used to print each letter 
as a confirmation of successfully executing a part of itself.


Thinking of it: Loading a KMS driver basically always necessitates a mode 
change on variable resolution platforms such as PCs. And changing mode requires 
clearing the screen. Now, what if we could preload the new framebuffer with a 
splash, rather than a blank screen?

That's not generally feasible (for example, double buffering is an implicit 
requirement), but who knows, maybe in the future. Just an odd idea.


> Of course, with the kernel developer hat on, I want all of the clues
> every time in case something goes wrong. But this shouldn't have to be
> mutually exclusive.

I agree - that's why it's important to be able to disable the bootsplash by 
changing the kernel cmdline.


Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/21/2017 10:48 AM, Daniel Vetter wrote:
> Ok, here's my expectation:
> 
> - fix plymouth and driver loading
> 
> If the plymouth maintainer tells me that's impossible, I'll look at this
> again. And no, this does not require killing drivers with SIGBUS, at least
> not with drm. Meanwhile I don't think this RFC makes sense to be merged.
I'm afraid I don't understand. How would we best go about fixing this issue?



Thank you for your valuable feedback so far, I'll be looking into addressing 
the issues you've brought up.

For now, I'll be on vacation until January 2018, so it'll take a while until I 
get back to you.



Thanks and happy new year!

Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/21/2017 03:51 PM, Ray Strode wrote:
> Hi,
> 
> On Wed, Dec 20, 2017 at 11:44 AM Max Staudt <msta...@suse.de> wrote:
>> It'd be nice to see this bug fixed, as it happens only occasionally (as is 
>> the nature of a
>> race condition), and was thus really hard to debug. I'm sure it can drive 
>> people insane,
>> as they try to find out whether they've disabled Ctrl-Alt-Fx in their 
>> xorg.conf, but really
>> it's Plymouth getting the system into a bad state. I probably owe a bald 
>> patch on my
>> head to this bug.
> Okay, reading through the code I do see how what you're describing could 
> happen.
> 
> I sketched out a patch here:
> 
> https://cgit.freedesktop.org/plymouth/commit/?h=fix-vt-management-on-deactivate=0b5b790d628f4c96e3ab9fbc0daba67a29b850da
> 
> that I think should fix it.  I need to do some testing with it (ideally rig up
> a reproducer) before I push it.

Hmm, I haven't looked at what manager->renderers_activated means, but from just 
looking at the diff, it looks like it could solve the problem. Please do test 
it though! I'm afraid I can't really tell you how to rig up a reproducer, since 
it's a race condition. Maybe a sleep() in gdm, and then forcefully emptying the 
udev queue?

Are you sure that process_udev_event (manager) will do the right thing?
Will it keep a list of events not processed?

What if a card is plugged in, then unplugged? Would Plymouth then handle the 
plugin first, see that the card isn't there, and fail gracefully? And will it 
handle the unplug gracefully if the card wasn't there in the first place?

Or what if I plug in two cards - it needs to keep a list of events for this 
case, otherwise it will only detect one card when it resumes udev processing.

Maybe these concerns are unnecessary - I haven't looked at the full Plymouth 
code since. Just ideas to keep in mind when rigging up the patch.


Thanks for looking into a fix!


>> This is exactly where the kernel bootsplash is useful. Since it starts even 
>> before any
>> userspace program is loaded, it can close this gap.
>>
>> I've even tried it in combination with Plymouth: Plymouth is just another 
>> graphical
>> application, so it simply pops up "on top", just like X would. The two 
>> splashes
>> integrate flawlessly.
> I just wish it used our modern graphics platform instead of the
> deprecated subsystem.

I see, and I share your concern that legacy interfaces should die.
But with the current architecture in the kernel, building it on DRM wouldn't 
make sense, sorry.
Also, it would exclude the efifb case, which is decidedly a design requirement.


>> One could argue that one could put all DRM drivers into the initrd. Ubuntu 
>> does this,
>> and the initrd is ~40 MB in size. Not nice.
> well, that 40mb isn't just graphics drivers...
> ╎❯ du -sh /lib/modules/`uname -r`/kernel/drivers/gpu
> 2.7M /lib/modules/4.14.6-300.fc27.x86_64/kernel/drivers/gpu
> 
> 3M isn't too awful.

Oh, true. Weird, then I must have gotten something mixed up. That means there's 
truly tons of stuff in that initrd.


> But really you have two choices as I see it:
> 
> 1) make the initrd support new hardware
> 2) make the initrd be taylored to a specific configuration.
> 
> I actually think ubuntu has it right by doing 1. it's going to give
> the best user experience.
> (not just with graphics but other new hardware too).

Yes. Except when the mechanism fails.

And it doesn't cover the time before the driver is loaded.


> But if you do 2) then it's not unreasonable if things break with new
> hardware.

Agreed.


> Now
> ideally, the breakage would be as isolated as possible.  I mean maybe
> it's okay if the
> boot splash breaks (or shows a text splash),

Yup.


> but it's not okay if the
> bootsplash sort of
> works using /dev/fb, but then causes Xorg to break.  So we should
> probably change
> plymouth to avoid falling back to /dev/fb in the case where new
> hardware got added.
> Could probably fix this by detecting if kms is around when the initrd
> is generated,
> and adding a config option to skip fb renderer in that case.  or
> something like that.

That's not possible. When generating the initrd, you don't know where it will 
actually be booted next.

Practical example: Last year's installation media on next year's hardware.


> But the easy answer is to just fix the initrd to have the graphics drivers.

See above - you can't guarantee that I'm afraid.

Unless the distro decides to not care about vesafb/efifb, and just show the 
text mode plymouth splash in case no KMS driver has been loaded until then. 
That's what Fedora does when booted on non-EFI machines, since it boots in VGA 
text (non-graphics) mode. But ideally, we'd have a graphical 

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

[Max Staudt]

On 12/20/2017 04:35 PM, Ray Strode wrote:
> Hi,
> 
>> Actually, I don't want that :)
>>
>> This was a design decision that I've made to keep the code small and simple 
>> to audit.
>> As it is, the simple bootsplash code will make 99% of people happy.
> You think only 1% of linux users have more than one monitor or a 4k screen?

No, I think 99% will be glad to see a splash at all, and it's a 99% 
probabililty that the splash will look alright on at least one screen, if not 
more.

By the simple virtue that dual-monitor setups tend to use identical screens, 
it's okay if these are cloned while the splash is shown. So maybe 95% of these 
users are fine, as well.

As for 4k screens - a logo that looks okay on 800x600 will probably look fine, 
even though it's physically smaller, on a 4k screen.


If there really, really, really is a need, HiDPI can be retrofitted to the 
format later on.


>> I've made this decision from the point of view of someone who wants to ship 
>> a general
>> purpose distribution. If you have a look around and compare this to e.g. the 
>> Windows or
>> Mac OS X bootsplashes, the possibilities that my kernel code provides already
>> surpasses them.
> I haven't looked specifically, but I don't believe you :-)  You're
> telling me the apple boot
> splash isn't scaled up on machines with retina displays?  I don't use
> OSX (or windows),
> so I don't know, but I'd be really surprised.

Admittedly, my knowledge is aging as well. My pre-retina MacBook certainly 
didn't scale anything.

And Windows XP booted in 640x480, then went black, switched modes, and drew the 
desktop.


>> If you really want such sophisticated features, supplanting the initial 
>> bootsplash  with
>> Plymouth (or not using it at all) is a better solution. In my opinion, it is 
>> overengineering,
>> at least for kernel code.
> disagree..it's support for basic, commodity hardware these days.

Hmm. I guess it's a matter of taste, and we have to agree to disagree on this 
one. See above.

Also, like pointed out in the other email, it's meant as an alternative to 
Plymouth. Maybe I should have made this clear from the beginning - it's an 
option, not a replacement. We're in the FOSS ecosystem after all, where it's 
all about choice, and that choice exists because we admit that sometimes, not 
everyone can be made happy with the same solution.


>> As for HiDPI, if you're working on an embedded device with a fixed screen 
>> size -
>> say a phone - you can easily include a huge picture the size of the screen 
>> in the
>> bootsplash.
> I'm talking about a situation where you have a dell xps or whatever
> with an external
> monitor attached.  Each monitor should be able to show the splash
> without deforming
> it, and without making it huge or microscopic. pretty basic stuff...
See above. I doubt any other system cares.

And we can't even care before native driver KMS comes up, which may take a 
while, depending on the system.

I'd like to have this as an alternative to Plymouth in such setups.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 04:21 PM, Ray Strode wrote:
> If we've reached the scenario you're discussing above, the real
> failure is that the KMS
> driver took too long to load. DRM is the platform graphics api.  If
> it's not loading
> timely enough to show graphics then that's the problem!  It sounds
> like maybe in the
> above bug, you're just failing to load the drm driver in the initrd ?

This case needs to be handled.

Again, please read my bug report.

When the user changes graphics cards, the initrd does not contain the new 
driver. It's in the rootfs, if at all.

If it does happen to be on the rootfs, then it is potentially loaded after 
Plymouth has already opened /dev/fb0. And then the bug occurs.

Please don't say that I'm to blame for changing my graphics card. This is not 
fair.


And I have to admit, it's not even necessarily a bug. It's just the nature of 
the kernel/userspace split. All I know is that the boot failing due to this is 
not right, and horrible to debug the next time it happens to someone.


>> And then, if something causes Plymouth to sense a new device (such as 
>> Plymouth
>>  thinking that udev coldplug is complete), it will open the device, and as 
>> part of that,
>> call VT_SETMODE. This is unexpected, since "plymouth deactivate" should keep 
>> it
>> from doing this. And Plymouth's code architecture is such that this bug is 
>> hard to fix.
> If what you're describing is happening, this does sound like a bug. I
> don't think it
> should be hard to fix, if it's a problem. I'll look into it.

Thank you!

It'd be nice to see this bug fixed, as it happens only occasionally (as is the 
nature of a race condition), and was thus really hard to debug. I'm sure it can 
drive people insane, as they try to find out whether they've disabled 
Ctrl-Alt-Fx in their xorg.conf, but really it's Plymouth getting the system 
into a bad state. I probably owe a bald patch on my head to this bug.


>> [I] have decided to write a kernel-based replacement to simplify things and 
>> to show a
>> splash as early as possible. It just avoids all of this complexity.
> So, for the record, I don't actually have a problem with you doing a
> kernel based splash.

Thanks!

It's really just meant as an alternative. I've heard enough people who'd prefer 
it over Plymouth, but Plymouth is just as important as it is much more 
feature-rich.


>> This is the sleep that I mean.
>>
>> On the one hand, it is this delay that makes most users not notice the
>> "busy VRAM bug". If the DRM driver that replaces the FB driver is included 
>> in the
>> initramfs, then in most cases, it will be loaded before the 5 seconds are 
>> up. However,
>> if the driver is loaded after these 5 seconds have elapsed, then Plymouth 
>> will have
>> opened /dev/fb0 and the modprobe fails.
> Think of this from a user perspective.  If the screen is black for 15 seconds
> (or something) before a splash is shown, then we've already hit a
> problem! That's like 15
> seconds of time where the user is wondering if their system is broken.

This is exactly where the kernel bootsplash is useful. Since it starts even 
before any userspace program is loaded, it can close this gap.

I've even tried it in combination with Plymouth: Plymouth is just another 
graphical application, so it simply pops up "on top", just like X would. The 
two splashes integrate flawlessly.


> But I don't think that actually happens in practice.  I think (maybe?)
> the situation you're
> hitting is your drm driver isn't starting to get loaded until N
> seconds after boot has started,
> because it's not in the initrd.  So the fix is to put it in the initrd.
No. See above.

One could argue that one could put all DRM drivers into the initrd. Ubuntu does 
this, and the initrd is ~40 MB in size. Not nice.

And even then, the initrd could be outdated for some reason. Maybe it's a 
developer machine. Nobody would expect the boot to hang/fail because of this 
problem.


>> On the other hand, what is the motivation for this delay?
> As I said earlier, the motivation for the delay is to avoid showing a
> splash for systems that
> boot in 4 seconds or something. At that point a splash is just getting
> in the way.
> 
>>  If Plymouth were to display the splash instantly on a system that needs 0.5 
>> seconds to
>> boot, then the splash would flash for 0.5 seconds.
> No, flashing a splash for half a second would be a bug. (again think
> of things from a user
> perpective).  Plymouth splashes have animations at the end to
> transition the user to the
>  login screen.  Normally those animations don't contribute to boot
> time, because we know
> when boot will finish from prior boot data.  But if boot were 0.5
> seconds long, then those
>  animations would contribute 2 to 3 seconds to boot time, and if boot
> is 0.5 seconds long
> showing a splash is pointless.
>> But with the delay, a system that needs 5.5 seconds to boot will also flash 
>> it for 0.5 seconds.
>> Either way, the splash will 

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 04:19 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
>> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt <msta...@suse.de> wrote:
>>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>>>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>>>> support this. I think bootsplash in kernel has a bunch of uses, and it
>>>> shouldn't be hard to get non-suse people to cheer for it (makes merging
>>>> easier if it's not just a one-off hack).
>>>
>>> Thank you!
>>>
>>> As it seems, other people and distros are already interested - for example 
>>> Manjaro.
>>>
>>> It's also a chance to (maybe in the near future) integrate with a splash 
>>> painted by EFI and/or GRUB, before userspace has even started.
>>
>> Maybe I've sounded too optimistic now.
>>
>> 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
>> 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.
>>
>> Your proposal to work on top of fbcon doesn't fix that niche.
>>
>> Now for your problem, which seems to be to have a working bootsplash
>> for a general purpose distro, specifically for the bug where plymouth
>> prevents the real drm driver from loading: Adding an in-kernel
>> bootsplash doesn't make any sense, at least not to me. Instead I think
>> the right action is to fix the problem, both in the kernel and in
>> userspace.
>>
>> All the problems below have fairly simple solutions, but there's imo
>> no point in talking technical solutions for specific problems when
>> we're trying to fix the wrong problem.
> 
> Aside: The problem you think you need the vt/console subsystem for is
> simple to fix with plain kms: kms works without fbdev, fbcon and the
> entire vt subsystem. Dislay ownership is controlled through the drm
> master concept. That's the exact same trick that we're using already
> to figure out whether fbdev (not just fbcon) is allowed to touch the
> display hw.

So when there is no DRM master, then the FB emulation becomes active.

Sure. But I still have to multiplex between the console and the splash.
It seemed cleanest to do this inside the console. If there's a good way 
outside, that's just as good for me, and I'm happy to implement it.
But please help me and point me at how to do it best. Ideally, in both FB and 
KMS contexts. Without using additional video RAM wherever possible.


> So yeah, there's a solution, and a modern system definitely would not
> want to get encumbered with the entire vt subsystem to be able to use
> a bootsplash. David Herrman had the entire pile prototyped btw,
> including userspace console on top of drm, emergency log on top of
> drm, and replacement for simpledrm. Adding an in-kernel boot splash
> would be fairly simple for this setup. It's just that no one else
> cared enough to get it merged.

So... the solution for being unable to implement a good splash in userspace 
is... to move the console into the userspace?

A ton of people will beg to differ. And I'm afraid I have to disagree as well.


To be clear, I dislike the nature of the VT subsystem as well. It's a hack. But 
it's such an incredibly useful hack that I'm willing to turn a blind eye to its 
ugliness. There's a good reason why we have a terminal emulator in the kernel 
itself, and I'd rather keep it around for a while longer.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 04:11 PM, Daniel Vetter wrote:
> 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
> 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.

If an embedded distro can use it, then so can a general purpose distro that 
doesn't want to use Plymouth.

It's useful in many cases.


> Your proposal to work on top of fbcon doesn't fix that niche.

It does fix it very well - it's just that it also requires fbcon.
And I'm glad to fix this if you have a good idea for a cleaner alternative.


> Now for your problem, which seems to be to have a working bootsplash
> for a general purpose distro, specifically for the bug where plymouth
> prevents the real drm driver from loading: Adding an in-kernel
> bootsplash doesn't make any sense, at least not to me. Instead I think
> the right action is to fix the problem, both in the kernel and in
> userspace.

So we SIGBUS any process using the framebuffer just because we're loading an 
alternative driver, which uses a hack to kick out the old driver?

It's loading the new driver that should fail because the hardware resource is 
busy serving the old driver!
Not existing applications being killed. This is horribly broken semantics.

Just like unloading a driver that's still in use MUST fail. Not kill the 
processes using it!

And if it fails to load with -EBUSY, as it should, then the bug still stands.


> All the problems below have fairly simple solutions, but there's imo
> no point in talking technical solutions for specific problems when
> we're trying to fix the wrong problem.

The problem is that a splash in userspace brings horrible hacks and workarounds 
into the room. We're already discussing killing processes!

No, just no. Processes aren't ours to kill willy-nilly.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 11:14 AM, Daniel Vetter wrote:
> btw since I'm probably sounding a bit too grumpy here: I'd very much
> support this. I think bootsplash in kernel has a bunch of uses, and it
> shouldn't be hard to get non-suse people to cheer for it (makes merging
> easier if it's not just a one-off hack).

Thank you!

As it seems, other people and distros are already interested - for example 
Manjaro.

It's also a chance to (maybe in the near future) integrate with a splash 
painted by EFI and/or GRUB, before userspace has even started.


> But I'm really not sold on the current integration path being anywhere
> near close to a good idea long-term.
Sure, that's a valid concern.

So there's two questions I understand from you here:

1. Do I really need to build on top of the console driver?
2. If not (1), then can I build on top of KMS instead?


Let's look at this...

1. The starting point was that the kernel's built-in terminal emulator, fbcon, 
is the "fallback" thing to display when no graphical application is running. It 
is hidden automatically as soon as a program switches to KD_GRAPHICS, and 
reappears as soon as that program switches back to KD_TEXT, or dies.
It seemed desirable to me to want the same behavior for a splash screen.

Furthermore, when fbcon runs, there is already a mode set. Whatever mode that 
may be, it's good enough for us.
It makes sense to re-use the same mode.
(This isn't really important for FB, but would be important when talking about 
drmcon).

Since fbcon and the splash will never be shown at the same time, it makes sense 
to re-use whatever framebuffer fbcon is writing into, and silence fbcon during 
this time (that's what my dummyops do).

When the splash is disabled, it needs to show the text that was hidden. So what 
I do is to call update_screen(vc_cons[fg_console].d) and also restore the 
original fbcon character rendering operations, thus allowing it to re-render 
the screen.


It thus seemed sensible to me to work inside of fbcon.


Let's stay at the FB level for the sake of taking things step by step. How 
would I solve this without hooking into fbcon?

To shut up fbcon, I could play with do_console_blank() and 
do_console_unblank(). These are called when changing between KD_GRAPHICS and 
KD_TEXT. I'd then have to introduce additional logic for the KD_TEXT state, 
which switches between showing fbcon and showing the splash. I haven't tried 
this, but fair enough.

To decide when to render, I'd have to have a hook that tells me when an FB mode 
changes, or the device disappears, or a new device appears. With fbcon, I can 
simply draw my splash in the fbcon_switch() function, not needing to care about 
whether this is a good time and whether I have a device underneath my feet. If 
fbcon can draw, then so can I.


2. Let's assume we follow the ideas from the final paragraphs of (1) above, and 
also move to KMS. How would I deal with setting modes, etc.? I wouldn't want to 
change modes, and I also can't always get a new framebuffer for background 
buffering - think devices that only have a single framebuffer, such as a 
fictional efidrm, or devices with little VRAM. So if these semantics get 
figured out for a future drmcon, then it makes sense to just double-purpose its 
framebuffer. After all, the console framebuffer is the one shown as a fallback, 
when no other process is using the graphics mode. Otherwise, I'd have to check 
which one to show: The splash, or the text?



So... it seemed helpful to me to build on top of the graphical console driver 
and double-purpose it, because it takes away the need to think about "what mode 
do I use", "which framebuffer to draw on", "when is it safe to draw", and so 
forth.

If you disagree with that, or even think that it's easier to do outside fbcon, 
I'd be grateful to hear ideas on how to implement it. Maybe it wasn't the best 
decision - but as the old saying goes, "it seemed like a very good idea at the 
time".


As for the FB/KMS discussion:
Since I decided to build on top of the only graphical console driver that we 
have, I have no choice: fbcon builds on fbdev, and thus the bootsplash is on 
fbdev, too. Complaining that it's not on KMS is a red herring - after all, it 
does work on KMS drivers, and people are happy with fbcon on KMS as well.


If integration and future paths are to be discussed, let's first talk about 
whether to move the splash inside/outside the console driver (fbcon).



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/20/2017 11:06 AM, Neil Armstrong wrote:
> My 2cents about this patchset:
> You did a good job about all the animation and splash logic, but for me all 
> this fbcon
> stuff is a huge hack, please use a standard and modern display subsystem en 
> leave fbcon
> die alone

Thanks for the compliment!

As for fbcon: I think you're confusing things. fbcon is not the same as fbdev.

I've hooked into the terminal emulator because it allows me to hide exactly the 
thing I want to hide (text), it allows me to show what I want when I want 
(splash or text), and it spares me from defining a third competing user of the 
device.

I understand that you want old code to die, and as it is now, catering for the 
old code will cater for everyone, including the new style drivers (via their 
legacy interface).


> My DRM ARM systems would love to have such bootsplash, so please, make it 
> happen using DRM
> then leave the fbcon based stuff like efifb migrate to DRM in a second time !
The current solution will "just work" on your systems as it is. I'm not 
ignoring them. If you've ever used a kernel console on your DRM ARM device, 
then the current splash will work exactly as good.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

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

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

[Max Staudt]

On 12/19/2017 10:01 PM, Ray Strode wrote:
> Hi,
> 
> On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt <msta...@suse.de> wrote:
>> 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.
>>
>> And the console in turn happens to work on all FB and KMS drivers, so it
>> makes users of all kinds of drivers happy. In fact, that's why the FB 
>> emulation
>> in KMS drivers came to be in the first place, if I remember right - to ensure
>> fbcon continues to work.
> 
> But what about multi-monitor? what about hidpi screens?  Ideally you want
> each monitor to show the splash in a way that best fits that monitor.

Actually, I don't want that :)

This was a design decision that I've made to keep the code small and simple to 
audit.
As it is, the simple bootsplash code will make 99% of people happy. It includes 
positioning of objects in corners and in the center, and a background color, 
and thus can render something that doesn't look funny in all but the most 
extreme cases.

I've made this decision from the point of view of someone who wants to ship a 
general purpose distribution. If you have a look around and compare this to 
e.g. the Windows or Mac OS X bootsplashes, the possibilities that my kernel 
code provides already surpasses them.

If you really want such sophisticated features, supplanting the initial 
bootsplash  with Plymouth (or not using it at all) is a better solution. In my 
opinion, it is overengineering, at least for kernel code.


So... I'll just take what the fbdev emulation gives me. In most cases (single 
screen systems), this looks good. In most remaining cases, you have two 
identical monitors that show exactly the same thing. And whatever remains can 
live with whatever mode the DRM driver decides to set for the fbdev emulation.


As for HiDPI, if you're working on an embedded device with a fixed screen size 
- say a phone - you can easily include a huge picture the size of the screen in 
the bootsplash.


Again, it's feature creep now. Apple just centers a, well, an apple in the 
middle of the screen. Windows may even boot in 640x480 and then do a mode 
switch when showing the desktop (not sure whether this is still true with the 
latest version). Neither of them scales for HiDPI, and neither cares about 
multiple monitors. People are happy.


So in the end, it's a matter of taste. I agree that in user space, exploring 
these features is fun. But in kernel space, it's definitely important to keep 
the code short and simple. I'm convinced that I've found a good balance :)


Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/19/2017 09:30 PM, Ray Strode wrote:
> Hi,
> 
>> For example, having a userspace splash that starts as early as it can
>> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail
>> reserving the entirety of video RAM, and thus fail loading. This cannot be 
>> fixed.
> well the fix there is to use drm devices... like this:
> 
> https://cgit.freedesktop.org/plymouth/commit/?id=97f02ee959374afb1b8a78dc67116cd880cf2d23

Sorry, you're confusing things. Please re-read the v1 cover letter, the commit 
message for patch 1, and the associated discussions.

There is also a bug report where I've described what happens - I think it 
clarifies the situation a lot:
  https://bugzilla.opensuse.org/show_bug.cgi?id=980750


To summarise: What you mean is for Plymouth to ignore FB devices when they have 
equivalent DRM devices. And yes, Plymouth does that just fine.

The problem that I am stumbling upon is different:
 - the system starts with an FB driver
 - after the ShowDelay time, Plymouth opens /dev/fb0
 - the system finally loads the DRM driver, which tries to kick the previous FB 
driver
 - loading the DRM driver fails because Plymouth still has the previous 
/dev/fb0 open


It's a wholly different issue.


>> Furthermore, Plymouth is quite broken. For example, it may lock
>> (via VT_SETMODE) the VT even though Plymouth is in "disabled"
>> state and X has already taken control of the VT.
> What do you mean by "disabled" (plymouth.enable=0?) ?  if it's
> disabled, it's not going to call VT_SETMODE ...

1. System boots
2. Plymouth starts and grabs some displays
3. gdm starts and runs /usr/bin/plymouth deactivate
4. X server grabs VT
5. udev queue is empty
6. Plymouth thinks that coldplugging has finished, and grabs remaining displays
7. 
8. gdm runs /usr/bin/plymouth quit --retain-splash


> Why do you refer to VT_SETMODE as locking ?

It's not a lock in the concurrency sense, sure.

If you have a better way of calling it, I'd be glad to learn.
Maybe "grabbing the VT", "taking ownership of the VT", ...?


> VT_SETMODE sets
> whether a process handles VT changes or the kernel does.  There is a
> long standing kernel issue where a mode of VT_AUTO (kernel handles
> vt switching) + KDGRAPHICS means VTs can't be changed. is that what
> you're talking about?

No, that's not what I mean. I've inserted printk()s in the kernel, and I've 
seen the X server's PID being thrown out when Plymouth calls VT_SETMODE. Once 
this happens, the kernel can no longer tell X to release the display.

The VT_SETMODE API is meant to be used by a single user at a time, not by two 
concurrently. It was built in a time when it was assumed that nobody other than 
the X server would use it.


> Anyway plymouth is only going to step on X's toes, if the distro erroneously
> asks it to.  Normally, a distro would run "plymouth deactivate" before
> starting X, instead of trying to run them at the same time...

That's what gdm, sddm, etc. do.

And then, if something causes Plymouth to sense a new device (such as Plymouth 
thinking that udev coldplug is complete), it will open the device, and as part 
of that, call VT_SETMODE. This is unexpected, since "plymouth deactivate" 
should keep it from doing this. And Plymouth's code architecture is such that 
this bug is hard to fix.

This is accurate as of about one year ago. I haven't looked into it since, but 
have decided to write a kernel-based replacement to simplify things and to show 
a splash as early as possible. It just avoids all of this complexity.


>> This causes the kernel to throw away X's PID as the VT owner, and thus
>> chvt and Ctrl-Alt-Fx no longer work because X can neither release the
>> console (VT_RELDISP fails), nor does the kernel send it the signal to do
>> so. This is hard to impossible to fix.
> Unless i'm missing something, this is totally just a problem with startup
> scripts not doing the right thing?  Plymouth shouldn't be doing anything
> once X is started.  If it is, that's either a plymouth bug (or more likely a
> distro integration problem)

It is a Plymouth bug, see above.


>> A third reason is that in practice, Plymouth's start is delayed for reasons
>> such as the above. Yes, race conditions are being worked around with
>> sleeps.
> ??? that's not true.  We don't have any sleep statements in the code to work
> around race conditions with X.
> 
> We do have two configurable delays in the code, are you talking about one of
> them?
> 
> 1) The first is a ShowDelay option.  The point of this option is,
> "If boot takes 5 seconds or less, it's essentially instant and we
> shouldn't show a splash at all".  Nothing to do with race conditions.
> You can set it to 0 if you want.

This is the sleep that I mean.

On the one hand, it is this delay that makes most users not notice the "busy 
VRAM bug". If the DRM driver that replaces the FB driver is included in the 
initramfs, then in most cases, it will be loaded before the 5 seconds are up. 
However, if the driver is 

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt <msta...@suse.de> wrote:
>> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a 
>> difference anyway if they're powerful enough to run Linux. As long as the 
>> bootsplash is shown, no fbcon drawing operations are executed, so there is 
>> no expensive scrolling or such to hog the system.
> 
> It's too big, and those folks tend to be super picky about space.

I know, they really are.

However, given just how big and clunky modern systems have become, I raise my 
doubts about a few extra KB for fbcon code to be relevant.

My feeling is that the kernel splash probably saves even more space on the 
userspace side than it adds on the kernel side, thus netting a reduction in 
overall code size.


> 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.


> 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?


> Also I'm not clear at all on the "papering over races with sleeps"
> part. DRM drivers shouldn't be racy when getting loaded ...

The DRM driver loading isn't racy, but the fbdev can't be fully unloaded while 
Plymouth has the address_space mmap()ed. If Plymouth sleeps until drivers that 
are included in initramfs are (hopefully) loaded, then it will forego using its 
FB backend.

A solution we've experimented with is dropping the FB backend from Plymouth. It 
instantly fixed the busy video RAM bug. However it made the folks relying on 
efifb very, very unhappy.


> 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.

Sure, that'd help a lot. But what do we do until then?



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

On 12/19/2017 05:16 PM, Daniel Vetter wrote:
> On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
>> Dear fbdev and fbcon developers,
>>
>> Thank you very much for your input for the first patch series.
>>
>> I've included your feedback into this second roll, and kindly ask for
>> your opinion on the new patch series.
> 
> Ok I've realized that my assumptions about why you need this aren't
> holding up.
> 
> So from reading these patches it sounded like you want an in-kernel boot
> splash because that would be on the display faster than a userspace one
> like plymouth. That's the only reasons I can see for this (if there's
> another good justification, please bring it up).

Yep, that's one of the reasons.

You can find a lot more in the commit message for my first patch.


For example, having a userspace splash that starts as early as it can (thus on 
vesafb/efifb on a PC) will cause the KMS driver to fail reserving the entirety 
of video RAM, and thus fail loading. This cannot be fixed.

Reproducer:  https://bugzilla.opensuse.org/show_bug.cgi?id=980750


Furthermore, Plymouth is quite broken. For example, it may lock (via 
VT_SETMODE) the VT even though Plymouth is in "disabled" state and X has 
already taken control of the VT. This causes the kernel to throw away X's PID 
as the VT owner, and thus chvt and Ctrl-Alt-Fx no longer work because X can 
neither release the console (VT_RELDISP fails), nor does the kernel send it the 
signal to do so. This is hard to impossible to fix.


A third reason is that in practice, Plymouth's start is delayed for reasons 
such as the above. Yes, race conditions are being worked around with sleeps. 
It'd be nice to have a splash as early as possible, without having to worry 
about races.


So some issues are hard to fix, others are impossible to fix in userspace. I 
figured that rather than hacking back and forth and defining APIs in both the 
kernel and userspace (redoing a sizable part of Plymouth, or writing a 
replacement), I might as well put small and simple code in the kernel straight 
away.

And if it's hooked into fbcon, we get stuff for free:
 - It shows *really* early, even before userland is available.
 - There are no fights, no races for the device. Of any kind.
 - The code is small and simple.


Further reasoning so far, from the comments to my v1 patch series:

  https://lkml.org/lkml/2017/11/10/374
  https://lkml.org/lkml/2017/11/9/324


> I only know of very embedded setups (tv top boxes, in vehicle
> entertainment) where that kind of "time to first image" really matters,
> and those systems:
> - have a real hw kms driver
> - don't have fbcon or fbdev emulation enabled (except for some closed
>   source stacks that are a bit slow to adapt to the new world, and we
>   don't care about those in gfx).

Well, those could enable fbcon if they want the bootsplash. Shouldn't make a 
difference anyway if they're powerful enough to run Linux. As long as the 
bootsplash is shown, no fbcon drawing operations are executed, so there is no 
expensive scrolling or such to hog the system.


> But from discussions it sounds like you very much want to use this on
> servers, which makes 0 sense to me. On a server something like plymouth
> should do a perfectly reasonable job.

As I said in the other thread, every little helps.

For example, even on a server, a nice bootsplash makes a Linux system more 
attractive to novice users.

On desktops, it's basically mandatory, as users seem to be scared of text 
scrolling by.


> So, why exactly do we need this?

For the aforementioned reasons, and to have a nice, unified bootsplash code on 
*all* devices.


> (let's stop the other thread meanwhile, there's no point discussing
> implementation details if the why? question isn't answered yet)

Sure, I hope this helps.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Max Staudt]

On 12/19/2017 05:09 PM, Daniel Vetter wrote:
> btw the reason drmcon didn't move is that David Herrmann moved on from
> hacking on graphics stuff, and no one needs it. There's nothing
> fundamentally wrong with his patches for a basic emergency console on
> plain drm, or the simpledrm driver to get a basic drm framebuffer up
> on vesafb/efifb and friends. Just wanted to bring this in since you
> sound like you're expecting this to magically have happened somehow.
> We don't merge code without real use-cases.

Don't worry, I'm not expecting this to have magically happened. It will happen 
when it will happen, or maybe never.

I'm just working with that I've got right now, and once a successor to fbcon 
takes it's throne, I'm very happy to help move the bootsplash over.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Max Staudt]

On 12/19/2017 05:02 PM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt <msta...@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 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

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

[Max Staudt]

On 12/19/2017 02:57 PM, Daniel Vetter wrote:
> Where do drivers deal with struct file deep down?

As an example, I remembered this to be the case in nouveau's code for 
allocating a framebuffer. So I checked, and it's much better now.

So I was mistaken about this - sorry.

Thanks a lot for cleaning up this part of DRM, I'm looking forward to a nicer 
future! Hopefully we can get unify the FB emulation in a single place at some 
point, but that's just my dreams and is going off-topic, so I'll stop here.


> 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?


> 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.

And the console in turn happens to work on all FB and KMS drivers, so it makes 
users of all kinds of drivers happy. In fact, that's why the FB emulation in 
KMS drivers came to be in the first place, if I remember right - to ensure 
fbcon continues to work.

Thus, once drmcon exists and becomes dominant over fbcon, moving the bootsplash 
to it makes sense. On the other hand, hooking into a raw video subsystem 
doesn't make sense as far as I can see, so a bootsplash on top of raw KMS is 
just as meaningless as a bootsplash on top of raw FB. So I have no choice but 
to work on top of fbcon, and thus use the FB subsystem.


> But if you insist on using fbdev, then I think the beast course
> here is to wire up a new fb_ops->flush callback.

Okay, makes sense. Thanks!


> Note that you only need to type the 1 trivial implementation for the drm
> fbdev emulation, as long as the callback is optional. Trying to make defio
> work correctly, as fbdev assumes it should work, in all cases, on top of
> drm is imo an entirely pointless endeavour.

I'll look into it.


> Yes, so lets ignore defio and do the flushing correctly, at least for kms
> drivers.

I agree.

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.


 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.
>>
>> Again, I don't understand.
>>
>> In my patch (see below), I explicitly check for info->fbdefio, as well
>> as three known broken drmfb emulations. I don't do the copy hack on any
>> other device.
> 
> Yeah, and if we'd to the explicit flush, you wouldn't even need to check
> for that. So
> 
> if (fbops->flush)
>   fbops->flush(); /* this covers all drm drivers */
> else if (fb->defio)
>   copyarea hack, if you really still need to support some defio
>   fbdev drivers, but really I think that's questionable

I need to support xenfb, thus I might as well support all defio drivers.

Also, I like that your suggestion allows for affected drivers to implement 
their own, more efficient fbops->flush() directly, while ensuring that those 
that don't still have a fallback, so there is some performance to be gained.

I'll look into implementing this.


> else
>   ; /* nothing */
> 
>> 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).

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.



Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Max Staudt]

On 12/19/2017 01:23 PM, Daniel Vetter wrote:
> On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
>> 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).
That's a general complaint about fbcon and/or the fbdev emulation in KMS 
drivers, right?

I can't see how it relates to my bootsplash, as I'm just replacing fbcon's 
output, wherever fbcon desires to draw at the given moment, and in no other 
case.

So when a graphical application sets the VT mode to KD_GRAPHICS, we get a call 
to do_blank_screen(), and then fbcon -and thus the bootsplash- is muted. The 
ioctl API has always been like this, and it's not specific to the patch in 
question.

Similarly, when a graphical application allocates a framebuffer via the KMS 
ioctl()s, and selects it for scanout, the driver will display that instead of 
the framebuffer it has allocated internally for the fbdev emulation.


>> 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.

Oh that's cool, I missed that. Thanks!

Maybe a fb2drm compat layer will become reality, after all.

The bootsplash code is fairly straightforward to port to a future drmcon, and 
I'm happy to make the changes once drmcon is available.
But for now, we only have fbcon. And a *lot* of FB drivers. And we want them to 
show a bootsplash instead of text. So that's where the bootsplash needs to hook 
into.


>> 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.

Sounds like the state of the art last year - drm_file in most cases, but struct 
file deep in the drivers :(


>> 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 :-)

So I must not touch fbops, correct?


>> 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.

I don't understand what you mean.

What I do know is that fb_defio is here, and it's here to stay because some 
drivers need it.

What I also know is that I need to flush the screen after drawing my bootsplash.


>> 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.

Again, I don't understand.

In my patch (see below), I explicitly check for info->fbdefio, as well as three 
known broken drmfb emulations. I don't do the copy hack on any other device.


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?



Max


> -Daniel
> 
>>
>>
>>>> +   *
>>>> +   * A few DRM drivers' FB implementations are broken by not using
>>>> +   * deferred_io when they really should - we m

Re: [RFC PATCH v2 01/13] bootsplash: Initial implementation showing black screen

[Max Staudt]

On 12/14/2017 12:55 AM, Randy Dunlap wrote:
> On 12/13/2017 11:47 AM, Max Staudt wrote:
>> This is the initial prototype for a lean Linux kernel bootsplash.
>>
>> As it is now, it will show a black screen rather than a logo, and
>> only if manually enabled via the kernel cmdline:
>>
>>   bootsplash.enable=1
> 
> Is it .enable or .enabled?  (compare below)

Oops. It's neither, I've kicked out the option and updated the documentation, 
but forgot about the commit message.


Thanks!

Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Max Staudt]

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.

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.

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.

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?

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.


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?


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

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

Unfortunately I've forgotten to rebase this patchset to 4.15, so it still 
builds on top of 4.14.

I'll rebase it for the next roll.


Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 11/13] bootsplash: sysfs entries to load and unload files

[Max Staudt]

Users can use this to replace their splash screen at runtime by writing
a path and filename to /sys/devices/platform/bootsplash.0/load_file and
making sure the splash is enabled.

Notes:
  - The path has to be a path in /lib/firmware since request_firmware()
is used to fetch the data.
  - When setting the splash from the shell, echo -n has to be used as
any trailing '\n' newline will be interpreted as part of the path.

Writes to /sys/devices/platform/bootsplash.0/drop_splash will cause the
current splash theme to be freed and the console to switch to text mode,

Signed-off-by: Max Staudt <msta...@suse.de>
---
 .../ABI/testing/sysfs-platform-bootsplash  | 32 +
 Documentation/bootsplash.rst   |  8 
 drivers/video/fbdev/core/bootsplash.c  | 54 ++
 3 files changed, 94 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-platform-bootsplash 
b/Documentation/ABI/testing/sysfs-platform-bootsplash
index 742c7b035ded..f8f4b259220e 100644
--- a/Documentation/ABI/testing/sysfs-platform-bootsplash
+++ b/Documentation/ABI/testing/sysfs-platform-bootsplash
@@ -9,3 +9,35 @@ Description:
1: Splash is shown whenever fbcon would show a text console
   (i.e. no graphical application is running), and a splash
   file is loaded.
+
+What:  /sys/devices/platform/bootsplash.0/drop_splash
+Date:  Oct 2017
+KernelVersion: 4.14
+Contact:       Max Staudt <msta...@suse.de>
+Description:
+   Can only be set.
+
+   Any value written will cause the current splash theme file
+   to be unloaded and the text console to be redrawn.
+
+What:  /sys/devices/platform/bootsplash.0/load_file
+Date:  Oct 2017
+KernelVersion: 4.14
+Contact:   Max Staudt <msta...@suse.de>
+Description:
+   Can only be set.
+
+   Any value written will cause the splash to be disabled and
+   internal memory structures to be freed.
+
+   A firmware path written will cause a new theme file to be
+   loaded and the current bootsplash to be replaced.
+   The current enabled/disabled status is not touched.
+   If the splash is already active, it will be redrawn.
+
+   The path has to be a path in /lib/firmware since
+   request_firmware() is used to fetch the data.
+
+   When setting the splash from the shell, echo -n has to be
+   used as any trailing '\n' newline will be interpreted as
+   part of the path.
diff --git a/Documentation/bootsplash.rst b/Documentation/bootsplash.rst
index 8bd6805af6bf..d793612ebf2e 100644
--- a/Documentation/bootsplash.rst
+++ b/Documentation/bootsplash.rst
@@ -58,6 +58,14 @@ sysfs run-time configuration
   a splash theme file is also loaded.
 
 
+``/sys/devices/platform/bootsplash.0/drop_splash``
+  Unload splash data and free memory.
+
+``/sys/devices/platform/bootsplash.0/load_file``
+  Load a splash file from ``/lib/firmware/``.
+  Note that trailing newlines will be interpreted as part of the file name.
+
+
 
 Kconfig
 ===
diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index 13fcaabbc2ca..16cb0493629d 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -251,11 +251,65 @@ static ssize_t splash_store_enabled(struct device *device,
return count;
 }
 
+static ssize_t splash_store_drop_splash(struct device *device,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct splash_file_priv *fp;
+
+   if (!buf || !count || !splash_state.file)
+   return count;
+
+   mutex_lock(_state.data_lock);
+   fp = splash_state.file;
+   splash_state.file = NULL;
+   mutex_unlock(_state.data_lock);
+
+   /* Redraw the text console */
+   schedule_work(_state.work_redraw_vc);
+
+   bootsplash_free_file(fp);
+
+   return count;
+}
+
+static ssize_t splash_store_load_file(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   struct splash_file_priv *fp, *fp_old;
+
+   if (!count)
+   return 0;
+
+   fp = bootsplash_load_firmware(_state.splash_device->dev,
+ buf);
+
+   if (!fp)
+   return -ENXIO;
+
+   mutex_lock(_state.data_lock);
+   fp_old = splash_state.file;
+   splash_state.splash_fb = NULL;
+   splash_state.file = fp;
+   mutex_unlock(_state.data_lock);
+
+   /* Update the splash or text console */
+   schedule_work(_state.work_redraw_vc);
+
+   bootsplash_free_file(fp_old);
+   return count;
+}
+
 stati

[RFC PATCH v2 08/13] sysrq: Disable bootsplash on SAK

[Max Staudt]

When the user requests a clean TTY via the SAK SysRq, that means he
really wants to use the console.

Let's disable the bootsplash, even if the request is not on a VT, as
the user probably knows what he's doing and it's more helpful to get
out of his way.

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/tty/sysrq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 3ffc1ce29023..bc6a24c9dfa8 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -104,6 +105,8 @@ static void sysrq_handle_SAK(int key)
 {
struct work_struct *SAK_work = _cons[fg_console].SAK_work;
schedule_work(SAK_work);
+
+   bootsplash_disable();
 }
 static struct sysrq_key_op sysrq_SAK_op = {
.handler= sysrq_handle_SAK,
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 02/13] bootsplash: Add file reading and picture rendering

[Max Staudt]

Load logo(s) from a file and render them in the center of the screen.

This removes the "black screen" functionality, which can now be emulated
by providing a splash file with no pictures and a black background.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 MAINTAINERS|   1 +
 drivers/video/fbdev/core/Makefile  |   2 +-
 drivers/video/fbdev/core/bootsplash.c  |  36 +++-
 drivers/video/fbdev/core/bootsplash_internal.h |  45 -
 drivers/video/fbdev/core/bootsplash_load.c | 225 +
 drivers/video/fbdev/core/bootsplash_render.c   | 103 ++-
 include/uapi/linux/bootsplash_file.h   | 118 +
 7 files changed, 522 insertions(+), 8 deletions(-)
 create mode 100644 drivers/video/fbdev/core/bootsplash_load.c
 create mode 100644 include/uapi/linux/bootsplash_file.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b5633b56391e..5c237445761e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2712,6 +2712,7 @@ S:Maintained
 F: drivers/video/fbdev/core/bootsplash*.*
 F: drivers/video/fbdev/core/dummycon.c
 F: include/linux/bootsplash.h
+F: include/uapi/linux/bootsplash_file.h
 
 BPF (Safe dynamic programs and tools)
 M: Alexei Starovoitov <a...@kernel.org>
diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
index 66895321928e..6a8d1bab8a01 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -31,4 +31,4 @@ obj-$(CONFIG_FB_SVGALIB)   += svgalib.o
 obj-$(CONFIG_FB_DDC)   += fb_ddc.o
 
 obj-$(CONFIG_BOOTSPLASH)   += bootsplash.o bootsplash_render.o \
-  dummyblit.o
+  bootsplash_load.o dummyblit.o
diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index e449755af268..843c5400fefc 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -32,6 +32,7 @@
 #include 
 
 #include "bootsplash_internal.h"
+#include "uapi/linux/bootsplash_file.h"
 
 
 /*
@@ -102,10 +103,17 @@ static bool is_fb_compatible(const struct fb_info *info)
  */
 void bootsplash_render_full(struct fb_info *info)
 {
+   mutex_lock(_state.data_lock);
+
if (!is_fb_compatible(info))
-   return;
+   goto out;
+
+   bootsplash_do_render_background(info, splash_state.file);
+
+   bootsplash_do_render_pictures(info, splash_state.file);
 
-   bootsplash_do_render_background(info);
+out:
+   mutex_unlock(_state.data_lock);
 }
 
 
@@ -116,6 +124,7 @@ bool bootsplash_would_render_now(void)
 {
return !oops_in_progress
&& !console_blanked
+   && splash_state.file
&& bootsplash_is_enabled();
 }
 
@@ -252,6 +261,7 @@ static struct platform_driver splash_driver = {
 void bootsplash_init(void)
 {
int ret;
+   struct splash_file_priv *fp;
 
/* Initialized already? */
if (splash_state.splash_device)
@@ -280,8 +290,26 @@ void bootsplash_init(void)
}
 
 
+   mutex_init(_state.data_lock);
+   set_bit(0, _state.enabled);
+
INIT_WORK(_state.work_redraw_vc, splash_callback_redraw_vc);
 
+
+   if (!splash_state.bootfile || !strlen(splash_state.bootfile))
+   return;
+
+   fp = bootsplash_load_firmware(_state.splash_device->dev,
+ splash_state.bootfile);
+
+   if (!fp)
+   goto err;
+
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   splash_state.file = fp;
+   mutex_unlock(_state.data_lock);
+
return;
 
 err_device:
@@ -292,3 +320,7 @@ void bootsplash_init(void)
 err:
pr_err("Failed to initialize.\n");
 }
+
+
+module_param_named(bootfile, splash_state.bootfile, charp, 0444);
+MODULE_PARM_DESC(bootfile, "Bootsplash file to load on boot");
diff --git a/drivers/video/fbdev/core/bootsplash_internal.h 
b/drivers/video/fbdev/core/bootsplash_internal.h
index b11da5cb90bf..71e2a27ac0b8 100644
--- a/drivers/video/fbdev/core/bootsplash_internal.h
+++ b/drivers/video/fbdev/core/bootsplash_internal.h
@@ -15,15 +15,43 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include "uapi/linux/bootsplash_file.h"
+
 
 /*
  * Runtime types
  */
+struct splash_blob_priv {
+   struct splash_blob_header *blob_header;
+   const void *data;
+};
+
+
+struct splash_pic_priv {
+   const struct splash_pic_header *pic_header;
+
+   struct splash_blob_priv *blobs;
+   u16 blobs_loaded;
+};
+
+
+struct splash_file_priv {
+   const struct firmware *fw;
+   const struct splash_file_header *header;
+
+   struct splash_pic_priv *pics;
+};
+
+
 struct splash_priv {
+   /* Bootup and runtime state */
+   char *bootfile;
+

[RFC PATCH v2 07/13] vt: Add keyboard hook to disable bootsplash

[Max Staudt]

Let's disable the splash if the user presses ESC or F1-F12 on a VT.

The F1-F12 check is to disable the splash on VT switches.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 drivers/tty/vt/keyboard.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index f4166263bb3a..a248429194bb 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -47,6 +47,8 @@
 
 #include 
 
+#include 
+
 extern void ctrl_alt_del(void);
 
 /*
@@ -1353,6 +1355,28 @@ static void kbd_keycode(unsigned int keycode, int down, 
int hw_raw)
}
 #endif
 
+   /* Trap keys when bootsplash is shown */
+   if (bootsplash_would_render_now()) {
+   /* Deactivate bootsplash on ESC or Alt+Fxx VT switch */
+   if (keycode >= KEY_F1 && keycode <= KEY_F12) {
+   bootsplash_disable();
+
+   /*
+* No return here since we want to actually
+* perform the VT switch.
+*/
+   } else {
+   if (keycode == KEY_ESC)
+   bootsplash_disable();
+
+   /*
+* Just drop any other keys.
+* Their effect would be hidden by the splash.
+*/
+   return;
+   }
+   }
+
if (kbd->kbdmode == VC_MEDIUMRAW) {
/*
 * This is extended medium raw mode, with keys above 127
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 12/13] tools/bootsplash: Add a basic splash file creation tool

[Max Staudt]

Signed-off-by: Max Staudt <msta...@suse.de>
---
 MAINTAINERS  |   1 +
 tools/bootsplash/.gitignore  |   1 +
 tools/bootsplash/Makefile|   9 +
 tools/bootsplash/bootsplash-packer.c | 471 +++
 4 files changed, 482 insertions(+)
 create mode 100644 tools/bootsplash/.gitignore
 create mode 100644 tools/bootsplash/Makefile
 create mode 100644 tools/bootsplash/bootsplash-packer.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7ffac272434e..ddff07cd794c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2715,6 +2715,7 @@ F:drivers/video/fbdev/core/bootsplash*.*
 F: drivers/video/fbdev/core/dummycon.c
 F: include/linux/bootsplash.h
 F: include/uapi/linux/bootsplash_file.h
+F: tools/bootsplash/*
 
 BPF (Safe dynamic programs and tools)
 M: Alexei Starovoitov <a...@kernel.org>
diff --git a/tools/bootsplash/.gitignore b/tools/bootsplash/.gitignore
new file mode 100644
index ..091b99a17567
--- /dev/null
+++ b/tools/bootsplash/.gitignore
@@ -0,0 +1 @@
+bootsplash-packer
diff --git a/tools/bootsplash/Makefile b/tools/bootsplash/Makefile
new file mode 100644
index ..0ad8e8a84942
--- /dev/null
+++ b/tools/bootsplash/Makefile
@@ -0,0 +1,9 @@
+CC := $(CROSS_COMPILE)gcc
+CFLAGS := -I../../usr/include
+
+PROGS := bootsplash-packer
+
+all: $(PROGS)
+
+clean:
+   rm -fr $(PROGS)
diff --git a/tools/bootsplash/bootsplash-packer.c 
b/tools/bootsplash/bootsplash-packer.c
new file mode 100644
index ..ffb6a8b69885
--- /dev/null
+++ b/tools/bootsplash/bootsplash-packer.c
@@ -0,0 +1,471 @@
+/*
+ * Kernel based bootsplash.
+ *
+ * (Splash file packer tool)
+ *
+ * Authors:
+ * Max Staudt <msta...@suse.de>
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+
+static void print_help(char *progname)
+{
+   printf("Usage: %s [OPTIONS] outfile\n", progname);
+   printf("\n"
+  "Options, executed in order given:\n"
+  "  -h, --help   Print this help message\n"
+  "\n"
+  "  --bg_red Background color (red part)\n"
+  "  --bg_green   Background color (green part)\n"
+  "  --bg_blueBackground color (blue part)\n"
+  "  --bg_reserved(do not use)\n"
+  "  --frame_ms  Minimum milliseconds between 
animation steps\n"
+  "\n"
+  "  --pictureStart describing the next 
picture\n"
+  "  --pic_width Picture width in pixels\n"
+  "  --pic_heightPicture height in pixels\n"
+  "  --pic_position  Coarse picture placement:\n"
+  "  0x00 - Top left\n"
+  "  0x01 - Top\n"
+  "  0x02 - Top right\n"
+  "  0x03 - Right\n"
+  "  0x04 - Bottom right\n"
+  "  0x05 - Bottom\n"
+  "  0x06 - Bottom left\n"
+  "  0x07 - Left\n"
+  "\n"
+  "Flags:\n"
+  " 0x10 - Calculate offset from 
corner towards center,\n"
+  " rather than from 
center towards corner\n"
+  "  --pic_position_offset   Distance from base position in 
pixels\n"
+  "  --pic_anim_type  Animation type:\n"
+  " 0 - None\n"
+  " 1 - Forward loop\n"
+  "  --pic_anim_loop  Loop point for animation\n"
+  "\n"
+  "  --blob Include next data stream\n"
+  "  --blob_type Type of data\n"
+  "  --blob_picture_idPicture to associate this blob 
with, starting at 0\n"
+  " (default: number of last 
--picture)\n"
+  "\n");
+   printf("This tool will write %s files.\n\n",
+#if __BYTE_ORDER == __BIG_ENDIAN
+  "Big Endian (BE)");
+#elif __BYTE_ORDER == __LITTLE_ENDIAN
+  "Little Endian (LE)");
+#else

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

[Max Staudt]

Framebuffers with deferred I/O need to be flushed to the screen
explicitly, since we use neither the mmap nor the file I/O abstractions
that handle this for userspace FB clients.

Example: xenfb

Some framebuffer drivers implement lazy access to the screen without
actually exposing a fbdefio interface - we also match some known ones,
currently:
 - ast
 - cirrus
 - mgag200

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/video/fbdev/core/bootsplash.c  |  2 ++
 drivers/video/fbdev/core/bootsplash_internal.h |  1 +
 drivers/video/fbdev/core/bootsplash_render.c   | 33 ++
 3 files changed, 36 insertions(+)

diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index 843c5400fefc..815b007f81ca 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -112,6 +112,8 @@ void bootsplash_render_full(struct fb_info *info)
 
bootsplash_do_render_pictures(info, splash_state.file);
 
+   bootsplash_do_render_flush(info);
+
 out:
mutex_unlock(_state.data_lock);
 }
diff --git a/drivers/video/fbdev/core/bootsplash_internal.h 
b/drivers/video/fbdev/core/bootsplash_internal.h
index 71e2a27ac0b8..0acb383aa4e3 100644
--- a/drivers/video/fbdev/core/bootsplash_internal.h
+++ b/drivers/video/fbdev/core/bootsplash_internal.h
@@ -89,6 +89,7 @@ void bootsplash_do_render_background(struct fb_info *info,
 const struct splash_file_priv *fp);
 void bootsplash_do_render_pictures(struct fb_info *info,
   const struct splash_file_priv *fp);
+void bootsplash_do_render_flush(struct fb_info *info);
 
 
 void bootsplash_free_file(struct splash_file_priv *fp);
diff --git a/drivers/video/fbdev/core/bootsplash_render.c 
b/drivers/video/fbdev/core/bootsplash_render.c
index 2ae36949d0e3..8c09c306ff67 100644
--- a/drivers/video/fbdev/core/bootsplash_render.c
+++ b/drivers/video/fbdev/core/bootsplash_render.c
@@ -186,3 +186,36 @@ void bootsplash_do_render_pictures(struct fb_info *info,
pp->pic_header->width, pp->pic_header->height);
}
 }
+
+
+void bootsplash_do_render_flush(struct fb_info *info)
+{
+   /*
+* FB drivers using deferred_io (such as Xen) need to sync the
+* screen after modifying its contents. When the FB is mmap()ed
+* from userspace, this happens via a dirty pages callback, but
+* when modifying the FB from the kernel, there is no such thing.
+*
+* So let's issue a fake fb_copyarea (copying the FB onto itself)
+* to trick the FB driver into syncing the screen.
+*
+* 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")) {
+   struct fb_copyarea area;
+
+   area.dx = 0;
+   area.dy = 0;
+   area.width = info->var.xres;
+   area.height = info->var.yres;
+   area.sx = 0;
+   area.sy = 0;
+
+   info->fbops->fb_copyarea(info, );
+   }
+}
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 13/13] tools/bootsplash: Add script and data to create sample file

[Max Staudt]

Also, mention this in the bootsplash documentation.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 Documentation/bootsplash.rst   |  10 ++
 tools/bootsplash/.gitignore|   3 ++
 tools/bootsplash/ajax-loader.gif   | Bin 0 -> 3208 bytes
 tools/bootsplash/bootsplash-tux.sh |  66 +
 4 files changed, 79 insertions(+)
 create mode 100644 tools/bootsplash/ajax-loader.gif
 create mode 100755 tools/bootsplash/bootsplash-tux.sh

diff --git a/Documentation/bootsplash.rst b/Documentation/bootsplash.rst
index d793612ebf2e..3ace027de357 100644
--- a/Documentation/bootsplash.rst
+++ b/Documentation/bootsplash.rst
@@ -183,3 +183,13 @@ Hooks - how the bootsplash is integrated
   ``kbd_keycode()`` can call ``bootsplash_disable()`` when the user
   presses ESC or F1-F12 (changing VT). This is to provide a built-in way
   of disabling the splash manually at any time.
+
+
+
+Crating a bootsplash theme file
+===
+
+A simple tool for theme file creation is included in ``tools/bootsplash``.
+
+There is also an example shell script, as an example on how to use the tool
+and in order to generate a reference bootsplash file.
diff --git a/tools/bootsplash/.gitignore b/tools/bootsplash/.gitignore
index 091b99a17567..5dfced41ba82 100644
--- a/tools/bootsplash/.gitignore
+++ b/tools/bootsplash/.gitignore
@@ -1 +1,4 @@
 bootsplash-packer
+bootsplash
+logo.rgb
+throbber*.rgb
diff --git a/tools/bootsplash/ajax-loader.gif b/tools/bootsplash/ajax-loader.gif
new file mode 100644
index 
..3288d1035d70bb86517e2c233f1a904e41f06b29
GIT binary patch
literal 3208
zcmc(iX;4#H9>pJdFE7h`I{IF)0|5<6L}(j=N}5%L009EB2nYfyF)E0PvIqo$u!IC;
z4PgyY5|S9AEh38G)(9eq4TbH7_UHg@yWrlIJ$6smIADL7s^P;_O;ykRc<bJ}b9soXl`UC*LwQJXkii*0rx|*7rI2=x7WaRkx_~XZqFJ8R3c=2Kg
zf@aSAv8+BJ8+^hyay>(QR@t*blbKzsf0}bscEqRc5Hd3o(-N5RyW=zWB*zQw6Zh>*
z2CROCDAbu#D`)S|J_<lj7Yz9)#_Og>o(lL9Yn3l*+8RdiRD_>iNz$#_IAzCna
zSF_(rRCDD!wi#i8oAm_@VB%2-H*G%bN#|(6R6N?wM)3u`PiGzwuX7qmTgyF
zpE)h0kuoxQ9?=kW7Y!=R@DmhU9)vwT<ZMc0Y;%TT3z!|H=R-GXDHPiKcVWh
zY+!etO=DI2rIs8{iFWtPv(Lu|O3u|$F3Sbq;+xF{gTX$#T%m?MUUZy$=zXgXj
zrxrf}reg*D3HB~8JyLgl$UCyV?EQ`@OKjW@tGrvh6ZqPD#+m=rK0T{FT01>*EZWzJ
zrt+=2tqFts72yIp?|gvdLhs8Hfku^Z(){gmN%Y=K#<L1VKWYjwV^JDyeS;Y$p1xw*
z#3VzfAV>P|%fkvg

[RFC PATCH v2 05/13] bootsplash: Add animation support

[Max Staudt]

Each 'picture' in the splash file can consist of multiple 'blobs'.

If animation is enabled, these blobs become the frames of an animation,
in the order in which they are stored in the file.

Note: There is only one global timer, so all animations happen at
  the same frame rate. It doesn't really make sense to animate
  more than one object at a time anyway.

Furthermore, this patch introduces a check for reusing a framebuffer
where the splash has recently been painted on - in this case, we only
redraw the objects that are animated.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 drivers/video/fbdev/core/bootsplash.c  | 62 +++---
 drivers/video/fbdev/core/bootsplash_internal.h | 13 +-
 drivers/video/fbdev/core/bootsplash_load.c | 21 +
 drivers/video/fbdev/core/bootsplash_render.c   | 30 -
 include/uapi/linux/bootsplash_file.h   | 35 ++-
 5 files changed, 151 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index 815b007f81ca..c8642142cfea 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -53,6 +53,14 @@ static void splash_callback_redraw_vc(struct work_struct 
*ignored)
console_unlock();
 }
 
+static void splash_callback_animation(struct work_struct *ignored)
+{
+   if (bootsplash_would_render_now()) {
+   /* This will also re-schedule this delayed worker */
+   splash_callback_redraw_vc(ignored);
+   }
+}
+
 
 static bool is_fb_compatible(const struct fb_info *info)
 {
@@ -103,17 +111,44 @@ static bool is_fb_compatible(const struct fb_info *info)
  */
 void bootsplash_render_full(struct fb_info *info)
 {
+   bool is_update = false;
+
mutex_lock(_state.data_lock);
 
-   if (!is_fb_compatible(info))
-   goto out;
+   /*
+* If we've painted on this FB recently, we don't have to do
+* the sanity checks and background drawing again.
+*/
+   if (splash_state.splash_fb == info)
+   is_update = true;
+
+
+   if (!is_update) {
+   /* Check whether we actually support this FB. */
+   splash_state.splash_fb = NULL;
+
+   if (!is_fb_compatible(info))
+   goto out;
+
+   /* Draw the background only once */
+   bootsplash_do_render_background(info, splash_state.file);
 
-   bootsplash_do_render_background(info, splash_state.file);
+   /* Mark this FB as last seen */
+   splash_state.splash_fb = info;
+   }
 
-   bootsplash_do_render_pictures(info, splash_state.file);
+   bootsplash_do_render_pictures(info, splash_state.file, is_update);
 
bootsplash_do_render_flush(info);
 
+   bootsplash_do_step_animations(splash_state.file);
+
+   /* Schedule update for animated splash screens */
+   if (splash_state.file->frame_ms > 0)
+   schedule_delayed_work(_state.dwork_animation,
+ msecs_to_jiffies(
+ splash_state.file->frame_ms));
+
 out:
mutex_unlock(_state.data_lock);
 }
@@ -169,8 +204,14 @@ void bootsplash_enable(void)
 
was_enabled = test_and_set_bit(0, _state.enabled);
 
-   if (!was_enabled)
+   if (!was_enabled) {
+   /* Force a full redraw when the splash is re-activated */
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   mutex_unlock(_state.data_lock);
+
schedule_work(_state.work_redraw_vc);
+   }
 }
 
 
@@ -227,6 +268,14 @@ ATTRIBUTE_GROUPS(splash_dev);
  */
 static int splash_resume(struct device *device)
 {
+   /*
+* Force full redraw on resume since we've probably lost the
+* framebuffer's contents meanwhile
+*/
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   mutex_unlock(_state.data_lock);
+
if (bootsplash_would_render_now())
schedule_work(_state.work_redraw_vc);
 
@@ -235,6 +284,7 @@ static int splash_resume(struct device *device)
 
 static int splash_suspend(struct device *device)
 {
+   cancel_delayed_work_sync(_state.dwork_animation);
cancel_work_sync(_state.work_redraw_vc);
 
return 0;
@@ -296,6 +346,8 @@ void bootsplash_init(void)
set_bit(0, _state.enabled);
 
INIT_WORK(_state.work_redraw_vc, splash_callback_redraw_vc);
+   INIT_DELAYED_WORK(_state.dwork_animation,
+ splash_callback_animation);
 
 
if (!splash_state.bootfile || !strlen(splash_state.bootfile))
diff --git a/drivers/video/fbdev/core/bootsplash_internal.h 
b/drivers/video/fbdev/core/bootsplash_internal.h
index 0acb383aa4e3..b3a74835d90f 100644
--- a/drivers/video/fbdev/core/bootsplash_internal.h
+++ b/drivers/v

[RFC PATCH v2 10/13] Documentation: Add bootsplash main documentation

[Max Staudt]

Signed-off-by: Max Staudt <msta...@suse.de>
---
 .../ABI/testing/sysfs-platform-bootsplash  |  11 ++
 Documentation/bootsplash.rst   | 177 +
 MAINTAINERS|   2 +
 3 files changed, 190 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-bootsplash
 create mode 100644 Documentation/bootsplash.rst

diff --git a/Documentation/ABI/testing/sysfs-platform-bootsplash 
b/Documentation/ABI/testing/sysfs-platform-bootsplash
new file mode 100644
index ..742c7b035ded
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-bootsplash
@@ -0,0 +1,11 @@
+What:  /sys/devices/platform/bootsplash.0/enabled
+Date:  Oct 2017
+KernelVersion: 4.14
+Contact:       Max Staudt <msta...@suse.de>
+Description:
+   Can be set and read.
+
+   0: Splash is disabled.
+   1: Splash is shown whenever fbcon would show a text console
+  (i.e. no graphical application is running), and a splash
+  file is loaded.
diff --git a/Documentation/bootsplash.rst b/Documentation/bootsplash.rst
new file mode 100644
index ..8bd6805af6bf
--- /dev/null
+++ b/Documentation/bootsplash.rst
@@ -0,0 +1,177 @@
+
+The Linux bootsplash
+
+
+:Date: November, 2017
+:Author: Max Staudt <msta...@suse.de>
+
+
+The Linux bootsplash is a graphical replacement for the '``quiet``' boot
+option, typically showing a logo and a spinner animation as the system starts.
+
+Currently, it is a part of the Framebuffer Console support, and can be found
+as ``CONFIG_BOOTSPLASH`` in the kernel configuration. This means that as long
+as it is enabled, it hijacks fbcon's output and draws a splash screen instead.
+
+Purely compiling in the bootsplash will not render it functional - to actually
+render a splash, you will also need a splash theme file. See the example
+utility and script in ``tools/bootsplash`` for a live demo.
+
+
+
+Motivation
+==
+
+- The '``quiet``' boot option only suppresses most messages during boot, but
+  errors are still shown.
+
+- A user space implementation can only show a logo once user space has been
+  initialized far enough to allow this. A kernel splash can display a splash
+  immediately as soon as fbcon can be displayed.
+
+- Implementing a splash screen in user space (e.g. Plymouth) is problematic
+  due to resource conflicts.
+
+  For example, if Plymouth is keeping ``/dev/fb0`` (provided via vesafb/efifb)
+  open, then most DRM drivers can't replace it because the address space is
+  still busy - thus leading to a VRAM reservation error.
+
+  See: https://bugzilla.opensuse.org/show_bug.cgi?id=980750
+
+
+
+Command line arguments
+==
+
+``bootsplash.bootfile``
+  Which file in the initrd to load.
+  Default: none, i.e. a non-functional splash, falling back to showing text.
+
+
+
+sysfs run-time configuration
+
+
+``/sys/devices/platform/bootsplash.0/enabled``
+  Enable/disable the bootsplash.
+  The system boots with this set to 1, but will not show a splash unless
+  a splash theme file is also loaded.
+
+
+
+Kconfig
+===
+
+``BOOTSPLASH``
+  Whether to compile in bootsplash support
+  (depends on fbcon compiled in, i.e. ``FRAMEBUFFER_CONSOLE=y``)
+
+
+
+Bootsplash file format
+==
+
+A file specified in the kernel configuration as ``CONFIG_BOOTSPLASH_FILE``
+or specified on the command line as ``bootsplash.bootfile`` will be loaded
+and displayed as soon as fbcon is initialized.
+
+
+Main blocks
+---
+
+There are 3 main blocks in each file:
+
+  - one File header
+  -   n Picture headers
+  -   m (Blob header + payload) blocks
+
+
+Structures
+--
+
+The on-disk structures are defined in
+``drivers/video/fbdev/core/bootsplash_file.h`` and represent these blocks:
+
+  - ``struct splash_file_header``
+
+Represents the file header, with splash-wide information including:
+
+  - The magic string "``Linux bootsplash``" on big-endian platforms
+(the reverse on little endian)
+  - The file format version (for incompatible updates, hopefully never)
+  - The background color
+  - Number of picture and blob blocks
+  - Animation speed (we only allow one delay for all animations)
+
+The file header is followed by the first picture header.
+
+
+  - ``struct splash_picture_header``
+
+Represents an object (picture) drawn on screen, including its immutable
+properties:
+  - Width, height
+  - Positioning relative to screen corners or in the center
+  - Animation, if any
+  - Animation type
+  - Number of blobs
+
+The picture header is followed by another picture header, up until n
+picture headers (as defined in the file header) have been read. Then,
+the (blob header, payload) pairs follow.
+
+
+  -

[RFC PATCH v2 01/13] bootsplash: Initial implementation showing black screen

[Max Staudt]

This is the initial prototype for a lean Linux kernel bootsplash.

It works by replacing fbcon's FB manipulation routines (such as
bitblit, tileblit) with dummy functions, effectively disabling text
output, and drawing the splash directly onto the FB device.

As it is now, it will show a black screen rather than a logo, and
only if manually enabled via the kernel cmdline:

  bootsplash.enable=1

There is a userland API via sysfs, to show/hide the splash on request
by dracut, systemd, or other init systems.

The reasons for implementing a bootsplash in kernel space are:

 - Quieting things more and nicer than with the quiet boot option:
   Currently the 'quiet' boot option does not remove the blinking
   cursor and errors are still printed. There are use cases where this
   is not desirable (such as embedded and desktop systems, digital
   signage, etc.) and a vendor logo is preferable.

 - Showing graphics, and never text, when the GUI crashes:
   This is an extension of the above use case, where recovery is meant
   to happen as invisibly to the user as possible. A system integrator
   needs the flexibility to hide "scary text" from users in all cases
   other than a panic.
   This is especially desirable in embedded systems such as digital
   signage.

 - Racy VT API:
   Userspace bootsplashes and GUIs (e.g. plymouth and X) tend to kick
   each other out via the non-exclusive KDSETMODE ioctl. This can
   result in situations such as the user being stuck in X with chvt
   and Ctrl-Alt-Fx no longer working.

 - Mode switching from FB to KMS:
   We cannot switch from a generic framebuffer (vesafb, efifb) to a
   KMS driver while a userspace splash keeps /dev/fb0 open. The device
   will vanish, but the address space is still busy, so the KMS driver
   cannot reserve its VRAM.

 - Simplification of userspace integration:
   Right now, hooking up a splash screen in userspace is quite complex.
   Having it in the kernel makes this a breeze, as hooks for
   switch_root, remounting r/w, etc. become obsolete.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 MAINTAINERS|   8 +
 drivers/video/console/Kconfig  |  24 ++
 drivers/video/fbdev/core/Makefile  |   3 +
 drivers/video/fbdev/core/bootsplash.c  | 294 +
 drivers/video/fbdev/core/bootsplash_internal.h |  55 +
 drivers/video/fbdev/core/bootsplash_render.c   |  93 
 drivers/video/fbdev/core/dummyblit.c   |  89 
 drivers/video/fbdev/core/fbcon.c   |  22 ++
 drivers/video/fbdev/core/fbcon.h   |   5 +
 include/linux/bootsplash.h |  43 
 10 files changed, 636 insertions(+)
 create mode 100644 drivers/video/fbdev/core/bootsplash.c
 create mode 100644 drivers/video/fbdev/core/bootsplash_internal.h
 create mode 100644 drivers/video/fbdev/core/bootsplash_render.c
 create mode 100644 drivers/video/fbdev/core/dummyblit.c
 create mode 100644 include/linux/bootsplash.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a74227ad082e..b5633b56391e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2705,6 +2705,14 @@ S:   Supported
 F: drivers/net/bonding/
 F: include/uapi/linux/if_bonding.h
 
+BOOTSPLASH
+M: Max Staudt <msta...@suse.de>
+L: linux-fb...@vger.kernel.org
+S: Maintained
+F: drivers/video/fbdev/core/bootsplash*.*
+F: drivers/video/fbdev/core/dummycon.c
+F: include/linux/bootsplash.h
+
 BPF (Safe dynamic programs and tools)
 M: Alexei Starovoitov <a...@kernel.org>
 M: Daniel Borkmann <dan...@iogearbox.net>
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..f3ff976266fe 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -151,6 +151,30 @@ config FRAMEBUFFER_CONSOLE_ROTATION
  such that other users of the framebuffer will remain normally
  oriented.
 
+config BOOTSPLASH
+   bool "Bootup splash screen"
+   depends on FRAMEBUFFER_CONSOLE
+   ---help---
+ This option enables the Linux bootsplash screen.
+
+ The bootsplash is a full-screen logo or animation indicating a
+ booting system. It replaces the classic scrolling text with a
+ graphical alternative, similar to other systems.
+
+ Since this is technically implemented as a hook on top of fbcon,
+ it can only work if the FRAMEBUFFER_CONSOLE is enabled and a
+ framebuffer driver is active. Thus, to get a text-free boot,
+ the system needs to boot with vesafb, efifb, or similar.
+
+ Once built into the kernel, the bootsplash needs to be enabled
+ with bootsplash.enabled=1 and a splash file needs to be supplied.
+
+ Further documentation can be found in:
+   Documentation/fb/bootsplash.txt
+
+ If unsure, say N.
+ This is typically used by distributors a

[RFC PATCH v2 09/13] fbcon: Disable bootsplash on oops

[Max Staudt]

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/video/fbdev/core/fbcon.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 9a39a6fcfe98..8a9c67e1c5d8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1343,6 +1343,16 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
int y;
int c = scr_readw((u16 *) vc->vc_pos);
 
+   /*
+* Disable the splash here so we don't have to hook into
+* vt_console_print() in drivers/tty/vt/vt.c
+*
+* We'd disable the splash just before the call to
+* hide_cursor() anyway, so this spot is just fine.
+*/
+   if (oops_in_progress)
+   bootsplash_disable();
+
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
 
if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1)
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 00/13] Kernel based bootsplash

[Max Staudt]

Dear fbdev and fbcon developers,

Thank you very much for your input for the first patch series.

I've included your feedback into this second roll, and kindly ask for
your opinion on the new patch series.


Changes from v1 to v2:

 + Added a user space tool to create splash theme files
 + Bumped the file format version:
- Larger structs for easy future expansion
- 2-byte corner offset
- Offset either from corner or from center
- Fixed padding before header->frame_ms
 + Moved bootsplash_file.h to uapi/linux
 + Merged several patches
 + Theme files are now loaded via request_firmware()
 + sysfs hook to allow loading of theme files via request_firmware()
 + Dropped the .enable cmdline option and the default file name.
   The splash will be shown as soon as a file is specified.
 + Dropped custom workqueue in favor of the kernel queue
   and cancel_delayed_work_sync()
 + Marked loaded data as const, and load/enable it atomically
 + Reduced global state by moving data into other structures
 + EXPORT_SYMBOL_GPL for fbcon_set_dummyops()
 + Atomic and barrier for splash enabled state instead of spinlock
 + Reduced warnings to infos
 + Rate limited printk
 + Changed the multi-line comment layout to kernel style
 + Simplified the file headers
 + reST-ed the documentation



Max





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 06/13] vt: Redraw bootsplash fully on console_unblank

[Max Staudt]

After exiting a KD_GRAPHICS program and falling back to the text
console, a previously enabled splash needs to be fully redrawn.

This corner case was introduced with selective re-drawing while
implementing animations.

Without this patch, the following happens:

1. Switch to a text console
2. Enable splash
3. Start X (or any other KD_GRAPHICS program)
4. Exit X
5. Splash is not seen, apart from animations

Signed-off-by: Max Staudt <msta...@suse.de>
Reviewed-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/tty/vt/vt.c   |  2 ++
 drivers/video/fbdev/core/bootsplash.c | 15 +--
 include/linux/bootsplash.h|  4 
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2ebaba16f785..416735ab6dc1 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -102,6 +102,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_NR_CON_DRIVER 16
 
@@ -3903,6 +3904,7 @@ void do_unblank_screen(int leaving_gfx)
}
 
console_blanked = 0;
+   bootsplash_mark_dirty();
if (vc->vc_sw->con_blank(vc, 0, leaving_gfx) || 
vt_force_oops_output(vc))
/* Low-level driver cannot restore -> do it ourselves */
update_screen(vc);
diff --git a/drivers/video/fbdev/core/bootsplash.c 
b/drivers/video/fbdev/core/bootsplash.c
index c8642142cfea..13fcaabbc2ca 100644
--- a/drivers/video/fbdev/core/bootsplash.c
+++ b/drivers/video/fbdev/core/bootsplash.c
@@ -165,6 +165,13 @@ bool bootsplash_would_render_now(void)
&& bootsplash_is_enabled();
 }
 
+void bootsplash_mark_dirty(void)
+{
+   mutex_lock(_state.data_lock);
+   splash_state.splash_fb = NULL;
+   mutex_unlock(_state.data_lock);
+}
+
 bool bootsplash_is_enabled(void)
 {
bool was_enabled;
@@ -206,9 +213,7 @@ void bootsplash_enable(void)
 
if (!was_enabled) {
/* Force a full redraw when the splash is re-activated */
-   mutex_lock(_state.data_lock);
-   splash_state.splash_fb = NULL;
-   mutex_unlock(_state.data_lock);
+   bootsplash_mark_dirty();
 
schedule_work(_state.work_redraw_vc);
}
@@ -272,9 +277,7 @@ static int splash_resume(struct device *device)
 * Force full redraw on resume since we've probably lost the
 * framebuffer's contents meanwhile
 */
-   mutex_lock(_state.data_lock);
-   splash_state.splash_fb = NULL;
-   mutex_unlock(_state.data_lock);
+   bootsplash_mark_dirty();
 
if (bootsplash_would_render_now())
schedule_work(_state.work_redraw_vc);
diff --git a/include/linux/bootsplash.h b/include/linux/bootsplash.h
index c6dd0b43180d..4075098aaadd 100644
--- a/include/linux/bootsplash.h
+++ b/include/linux/bootsplash.h
@@ -19,6 +19,8 @@ extern void bootsplash_render_full(struct fb_info *info);
 
 extern bool bootsplash_would_render_now(void);
 
+extern void bootsplash_mark_dirty(void);
+
 extern bool bootsplash_is_enabled(void);
 extern void bootsplash_disable(void);
 extern void bootsplash_enable(void);
@@ -31,6 +33,8 @@ extern void bootsplash_init(void);
 
 #define bootsplash_would_render_now() (false)
 
+#define bootsplash_mark_dirty()
+
 #define bootsplash_is_enabled() (false)
 #define bootsplash_disable()
 #define bootsplash_enable()
-- 
2.12.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 04/13] bootsplash: Add corner positioning

[Max Staudt]

This allows showing multiple logos, each in its own position,
relative to the eight screen corners.

Signed-off-by: Max Staudt <msta...@suse.de>
---
 drivers/video/fbdev/core/bootsplash_render.c | 136 ++-
 include/uapi/linux/bootsplash_file.h |  45 -
 2 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/core/bootsplash_render.c 
b/drivers/video/fbdev/core/bootsplash_render.c
index 8c09c306ff67..07e3a4eab811 100644
--- a/drivers/video/fbdev/core/bootsplash_render.c
+++ b/drivers/video/fbdev/core/bootsplash_render.c
@@ -155,6 +155,7 @@ void bootsplash_do_render_pictures(struct fb_info *info,
for (i = 0; i < fp->header->num_pics; i++) {
struct splash_blob_priv *bp;
struct splash_pic_priv *pp = >pics[i];
+   const struct splash_pic_header *ph = pp->pic_header;
long dst_xoff, dst_yoff;
 
if (pp->blobs_loaded < 1)
@@ -165,8 +166,139 @@ void bootsplash_do_render_pictures(struct fb_info *info,
if (!bp || bp->blob_header->type != 0)
continue;
 
-   dst_xoff = (info->var.xres - pp->pic_header->width) / 2;
-   dst_yoff = (info->var.yres - pp->pic_header->height) / 2;
+   switch (ph->position) {
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_TOP_LEFT:
+   dst_xoff = 0;
+   dst_yoff = 0;
+
+   dst_xoff += ph->position_offset;
+   dst_yoff += ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_TOP:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = 0;
+
+   dst_yoff += ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_TOP_RIGHT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_yoff = 0;
+
+   dst_xoff -= ph->position_offset;
+   dst_yoff += ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_RIGHT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_xoff -= ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_BOTTOM_RIGHT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+
+   dst_xoff -= ph->position_offset;
+   dst_yoff -= ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_BOTTOM:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+
+   dst_yoff -= ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_BOTTOM_LEFT:
+   dst_xoff = 0 + ph->position_offset;
+   dst_yoff = info->var.yres - pp->pic_header->height
+ - ph->position_offset;
+   break;
+   case SPLASH_POS_FLAG_CORNER | SPLASH_CORNER_LEFT:
+   dst_xoff = 0;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_xoff += ph->position_offset;
+   break;
+
+   case SPLASH_CORNER_TOP_LEFT:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_xoff -= ph->position_offset;
+   dst_yoff -= ph->position_offset;
+   break;
+   case SPLASH_CORNER_TOP:
+   dst_xoff = info->var.xres - pp->pic_header->width;
+   dst_xoff /= 2;
+   dst_yoff = info->var.yres - pp->pic_header->height;
+   dst_yoff /= 2;
+
+   dst_yoff -= ph->position_offset;
+   break;
+

[PATCH] drm/bochs: Implement nomodeset

[Max Staudt]

Up until now, the bochsdrm driver didn't handle the nomodeset option
at boot, and didn't provide a "modeset" module option either.

This patch implements both.

The new parameter can be used by specifying bochs-drm.modeset=0
at boot time.

Signed-off-by: Max Staudt <msta...@suse.de>
Cc: Gerd Hoffmann <kra...@redhat.com>
Cc: David Airlie <airl...@gmail.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bochs/bochs_drv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 15a293e..443374b 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -12,6 +12,10 @@
 
 #include "bochs.h"
 
+static int bochs_modeset = -1;
+module_param_named(modeset, bochs_modeset, int, 0444);
+MODULE_PARM_DESC(modeset, "enable/disable kernel modesetting");
+
 static bool enable_fbdev = true;
 module_param_named(fbdev, enable_fbdev, bool, 0444);
 MODULE_PARM_DESC(fbdev, "register fbdev device");
@@ -215,6 +219,12 @@ static struct pci_driver bochs_pci_driver = {
 
 static int __init bochs_init(void)
 {
+   if (vgacon_text_force() && bochs_modeset == -1)
+   return -EINVAL;
+
+   if (bochs_modeset == 0)
+   return -EINVAL;
+
return drm_pci_init(_driver, _pci_driver);
 }
 
-- 
2.6.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

gnome-shell is frozen upon wakeup from DPMS (bisected)

[Max Staudt]

Hi,

I have bisected a commit in v4.6 that fixes a freeze of the screen on
DPMS sleep:

777e3cbc791f131806d9bf24b3325637c7fc228d drm/radeon: Switch to drm_vblank_on/off


When running 'xset dpms force off' in a GNOME session (I tested this on
openSUSE Leap 42.2), sometimes the screen will freeze, sometimes it will
not. It may take several tries.

When it does freeze, the mouse can still be used, but clicking anything
will (seem to?) have no effect. Typing in an open terminal still works,
albeit the screen will still be frozen. Run "xterm" and the screen will
unfreeze. Running "xlogo" does not unfreeze it.


Can we include the above commit in linux-stable?

I have tested it on v4.4 - it applies cleanly and resolves the issue.



Thanks!

Max

[PATCH 2/3] Define fb_open_adj_file()

[Max Staudt]

On 05/24/2016 06:51 PM, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 6:28 PM, Max Staudt  wrote:
>> Hi Daniel,
>>
>> Thanks for the feedback! Comments below:
>>
>>
>> On 05/23/2016 03:44 PM, Daniel Vetter wrote:
>>> Do we _really_ care about fbdev mmap support so much that we want to add
>>> more hacks all over the place (in each driver) to make it work? Given that
>>> fbdev is officially in the "no more drivers" territory, I'm not sure we
>>> want this either.
>>>
>>> The trouble is that fbdev mmap and kms dumb buffer mmap have different
>>> semantics and so every driver needs to implement both if they're special
>>> in any kind of way.
>>
>> DRM drivers already have fbdev hacks in place in order to implement both 
>> semantics.
> 
> A lot of these fbdev hacks just disappeared since we've gained generic
> defio support in 4.7. Is your assertion still true on 4.7? I really
> don't want to grow hacks all over the place for something we should
> try to solve once for everyone.
> 
>> With this change, only bochsdrm(fb) will need to be touched, and if no 
>> further DRM driver implements fbdev support the way bochsdrmfb does, then no 
>> further driver will need this code.
> 
> See above - we've grown meanwhile enough drm drivers which need
> defio/special mmap support that there's now a pile of generic code and
> refactoring in 4.7. It's not just bochsdrm by far. Also pretty much
> every drm driver has their own pile of fbdev mmap hacks.
> 
>> This patch set is really just about setting file->f_mapping in bochsdrmfb's 
>> fb_open(), so we finally get rid of the WARNING.
>>
>> We could also pass file as a third paramenter in fb_open(), changing the 
>> function definition in all fbdev drivers. I'm happy to change the patch in 
>> that way if this is preferred.
>>
>>
>>> If we can't say no to fbdev mmap then I think we should implement
>>> something that works for all drivers. I'm thinking of allocating just a
>>> pile of pages in the fbdev emulation, and then copying them over using the
>>> defio stuff we just merged for 4.7 into a dumb bo, plus calling dirtyfb.
>>> Or at least something along those lines. Of couse just opt-in, in case the
>>> driver can do a more traditional mmio fbdev mmapping.
>>
>> Well, the mmap code is standard fbdev and it's already there, so why not 
>> keep it?
>>
>> All this patch series does is allowing bochsdrmfb to work properly until 
>> fbdev support is finally removed from the kernel.
> 
> I don't think we can remove fbdev in the next 10 years unfortunately.
> It's deprecated insofar that no new drivers are accepted. Instead
> proper kms drivers (with fbdev emulation) should be created.
> 
> But that means another decade of new drivers in kms that need to add
> hacks for fbdev mmap support, if we don't start to make this simpler
> and avoid the need for such special cases.
> 
> Anyway, that's kinda the high-level reasons why I jumped on this. I
> think for the next steps in the discussion you need to take a look at
> what's new in 4.7. And then we need to figure out what we need to add
> to improve fbdev mmap further.
> -Daniel


Thanks, I'll look into it.

Hm, sounds like it's best to ask the maintainer for advice, too.


Gerd, could you please have a look at this thread?



Thanks

Max

[PATCH 2/3] Define fb_open_adj_file()

[Max Staudt]

Hi Daniel,

Thanks for the feedback! Comments below:


On 05/23/2016 03:44 PM, Daniel Vetter wrote:
> Do we _really_ care about fbdev mmap support so much that we want to add
> more hacks all over the place (in each driver) to make it work? Given that
> fbdev is officially in the "no more drivers" territory, I'm not sure we
> want this either.
> 
> The trouble is that fbdev mmap and kms dumb buffer mmap have different
> semantics and so every driver needs to implement both if they're special
> in any kind of way.

DRM drivers already have fbdev hacks in place in order to implement both 
semantics.

With this change, only bochsdrm(fb) will need to be touched, and if no further 
DRM driver implements fbdev support the way bochsdrmfb does, then no further 
driver will need this code.


This patch set is really just about setting file->f_mapping in bochsdrmfb's 
fb_open(), so we finally get rid of the WARNING.

We could also pass file as a third paramenter in fb_open(), changing the 
function definition in all fbdev drivers. I'm happy to change the patch in that 
way if this is preferred.


> If we can't say no to fbdev mmap then I think we should implement
> something that works for all drivers. I'm thinking of allocating just a
> pile of pages in the fbdev emulation, and then copying them over using the
> defio stuff we just merged for 4.7 into a dumb bo, plus calling dirtyfb.
> Or at least something along those lines. Of couse just opt-in, in case the
> driver can do a more traditional mmio fbdev mmapping.

Well, the mmap code is standard fbdev and it's already there, so why not keep 
it?

All this patch series does is allowing bochsdrmfb to work properly until fbdev 
support is finally removed from the kernel.



Max

[PATCH 3/3] Add fb_open_adj_file() to bochsdrmfb to avoid use-after-free

['Max Staudt]

From: Max Staudt <msta...@suse.de>

Currently, when using bochsdrm(fb), opening /dev/drm/card0 will adjust
file->f_mapping, but opening /dev/fb0 will not.
This may result in dangling pointers from user space when memory is
evicted, and therefore in use-after-free crashes when using the emulated
framebuffer device.

Bochs is the only driver to use the TTM fbdev integration
(ttm_fbdev_mmap()), and thus the only one able to trigger this case.
It is highlighted by the WARN_ON() in ttm_bo_vm_open() in
drivers/gpu/drm/ttm/ttm_bo_vm.c which is printed upon splitting
a VMA (see reproducer code below):

WARN_ON(bo->bdev->dev_mapping != vma->vm_file->f_mapping);

This happens because ttm_fbdev_mmap() sets the VMA's vm_ops pointer
to point to the TTM memory handling functions, without the file's
f_mapping having been adjusted. This means that file->f_mapping would
still point to the address_space for the inode in the file system.

This patch avoids dangling/use-after-free pointers that remain after
TTM decides to evict the memory referenced by bo->bdev->dev_mapping,
as the VMAs of a mmap()ed /dev/fb0 belong to /dev/fb0 instead of the
anonymous inode dev->anon_inode used by DRM.
It basically mimics the adjustment of file->f_mapping that is also
performed in drm_open() in drivers/gpu/drm/drm_fops.c.

For the original report, see:
https://lkml.kernel.org/g/s5hy49ue4y0.wl-tiwai at suse.de

The reproducer code is as follows:



int main(void)
{
void *addr;

int fd = open("/dev/fb0", O_RDONLY);
if (fd < 0)
err(1, "open");

addr = mmap(0, 8192, PROT_READ, MAP_SHARED, fd, 0);
if (addr == MAP_FAILED)
err(1, "1st mmap");

if (mmap(addr, 4096, PROT_READ, MAP_SHARED | MAP_FIXED | MAP_ANONYMOUS, 
-1, 0) == MAP_FAILED)
        err(1, "2nd mmap");

return 0;
}



Signed-off-by: Max Staudt 
---
 drivers/gpu/drm/bochs/bochs.h   |  1 +
 drivers/gpu/drm/bochs/bochs_fbdev.c | 19 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 19b5ada..c37d30a 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 

 #include 
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 7520bf8..fd70449 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -20,6 +20,24 @@ static int bochsfb_mmap(struct fb_info *info,
return ttm_fbdev_mmap(vma, >bo);
 }

+static int bochsfb_open_adj_file(struct fb_info *info, struct file *file)
+{
+   struct drm_fb_helper *helper = (struct drm_fb_helper *)info->par;
+   struct bochs_device *bochs =
+   container_of(helper, struct bochs_device, fb.helper);
+   struct drm_device *dev = bochs->dev;
+
+   /* Correct f_mapping here so it's consistent across the
+* fd's lifetime.
+* If this isn't done, the WARN_ON() in ttm_bo_vm_open()
+* will trip upon vma_split(), hinting that other memory
+* management nastiness may occur when TTM evicts.
+*/
+   file->f_mapping = dev->anon_inode->i_mapping;
+
+   return 0;
+}
+
 static struct fb_ops bochsfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = drm_fb_helper_check_var,
@@ -31,6 +49,7 @@ static struct fb_ops bochsfb_ops = {
.fb_blank = drm_fb_helper_blank,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_mmap = bochsfb_mmap,
+   .fb_open_adj_file = bochsfb_open_adj_file,
 };

 static int bochsfb_create_object(struct bochs_device *bochs,
-- 
2.6.6

[PATCH 2/3] Define fb_open_adj_file()

['Max Staudt]

From: Max Staudt <msta...@suse.de>

This callback from fb_open() allows a fbdev driver to adjust things such
as file->f_mapping to better represent the internal structures.

This is needed to allow TTM drivers using ttm_fbdev_mmap() to properly
set file->f_mapping to TTM's address_space from bo->bdev->dev_mapping,
as is done form /dev/drm/card* in drm_open().

Currently, bochsdrmfb is the only driver requiring this, and this
patch is a prerequisite to implement this in bochsdrmfb.

Signed-off-by: Max Staudt 
---
 drivers/video/fbdev/core/fbmem.c | 13 +
 include/linux/fb.h   |  7 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 913c496..ff5000e 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1471,6 +1471,19 @@ __releases(>lock)
if (info->fbdefio)
fb_deferred_io_open(info, inode, file);
 #endif
+   if (info->fbops->fb_open_adj_file) {
+   res = info->fbops->fb_open_adj_file(info, file);
+   if (res) {
+   /* If we got here, we also want to undo anything
+* that fbops->fb_open() may have done.
+*/
+   if (info->fbops->fb_release)
+   info->fbops->fb_release(info,1);
+
+   module_put(info->fbops->owner);
+   goto out;
+   }
+   }
 out:
mutex_unlock(>lock);
if (res)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index dfe8835..4131496 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -320,6 +320,13 @@ struct fb_ops {
/* called at KDB enter and leave time to prepare the console */
int (*fb_debug_enter)(struct fb_info *info);
int (*fb_debug_leave)(struct fb_info *info);
+
+   /* Called after fb_open() to adjust mappings when using
+* complex backends such as TTM.
+* For example, the bochsdrmfb driver needs to adjust
+* file->f_mapping so it can use ttm_fbdev_mmap().
+*/
+   int (*fb_open_adj_file)(struct fb_info *info, struct file *file);
 };

 #ifdef CONFIG_FB_TILEBLITTING
-- 
2.6.6

[PATCH 1/3] Add missing "goto out" after fbops->fb_open()

['Max Staudt]

From: Max Staudt <msta...@suse.de>

It doesn't make sense to execute any further actions after a failed
call to fbops->fb_open().

Signed-off-by: Max Staudt 
---
 drivers/video/fbdev/core/fbmem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 76c1ad9..913c496 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1462,8 +1462,10 @@ __releases(>lock)
file->private_data = info;
if (info->fbops->fb_open) {
res = info->fbops->fb_open(info,1);
-   if (res)
+   if (res) {
module_put(info->fbops->owner);
+   goto out;
+   }
}
 #ifdef CONFIG_FB_DEFERRED_IO
if (info->fbdefio)
-- 
2.6.6

[PATCH 0/3] Fix kernel WARNING in TTM/Bochs KMS driver

['Max Staudt]

This patch set addresses an instance of dangling/use-after-free
pointers that can occur in the bochsdrm driver.

The original report can be found at:
https://lkml.kernel.org/g/s5hy49ue4y0.wl-tiwai at suse.de

It can be tested using 'qemu-system-x86_64 -vga std' with any kernel
recent enough to ship the bochsdrm driver, and with the fbdev
emulation active.
In other words: Any modern distro's default setup will do.


Max Staudt



 [PATCH 1/3] Add missing "goto out" after fbops->fb_open()
 [PATCH 2/3] Define fb_open_adj_file()
 [PATCH 3/3] Add fb_open_adj_file() to bochsdrmfb to avoid