From: Max Staudt <hidden> Date: 2017-12-13 19:48:47
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
From: Max Staudt <hidden> Date: 2017-12-13 19:48:50
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 <redacted>
Reviewed-by: Oliver Neukum <oneukum@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(-)
@@ -206,9 +213,7 @@ void bootsplash_enable(void)if(!was_enabled){/* Force a full redraw when the splash is re-activated */-mutex_lock(&splash_state.data_lock);-splash_state.splash_fb=NULL;-mutex_unlock(&splash_state.data_lock);+bootsplash_mark_dirty();schedule_work(&splash_state.work_redraw_vc);}
@@ -272,9 +277,7 @@ static int splash_resume(struct device *device)*Forcefullredrawonresumesincewe'veprobablylostthe*framebuffer'scontentsmeanwhile*/-mutex_lock(&splash_state.data_lock);-splash_state.splash_fb=NULL;-mutex_unlock(&splash_state.data_lock);+bootsplash_mark_dirty();if(bootsplash_would_render_now())schedule_work(&splash_state.work_redraw_vc);
From: Max Staudt <hidden> Date: 2017-12-13 19:48:53
This allows showing multiple logos, each in its own position,
relative to the eight screen corners.
Signed-off-by: Max Staudt <redacted>
---
drivers/video/fbdev/core/bootsplash_render.c | 136 ++++++++++++++++++++++++++-
include/uapi/linux/bootsplash_file.h | 45 ++++++++-
2 files changed, 178 insertions(+), 3 deletions(-)
@@ -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){+caseSPLASH_POS_FLAG_CORNER|SPLASH_CORNER_TOP_LEFT:+dst_xoff=0;+dst_yoff=0;++dst_xoff+=ph->position_offset;+dst_yoff+=ph->position_offset;+break;+caseSPLASH_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;+caseSPLASH_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;+caseSPLASH_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;+caseSPLASH_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;+caseSPLASH_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;+caseSPLASH_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;+caseSPLASH_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;++caseSPLASH_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;+caseSPLASH_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;+caseSPLASH_CORNER_TOP_RIGHT:+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;+caseSPLASH_CORNER_RIGHT:+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;+break;+caseSPLASH_CORNER_BOTTOM_RIGHT:+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;+caseSPLASH_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/=2;++dst_yoff+=ph->position_offset;+break;+caseSPLASH_CORNER_BOTTOM_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;+caseSPLASH_CORNER_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;+break;++default:+/* As a fallback, center the picture. */+dst_xoff=info->var.xres-pp->pic_header->width;+dst_xoff/=2;+dst_yoff=info->var.yres-pp->pic_header->height;+dst_yoff/=2;+break;+}if(dst_xoff<0||dst_yoff<0
@@ -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.
@@ -0,0 +1,66 @@+#!/bin/bash+#+# A simple script to show how to create a bootsplash.+# Do with it whatever you wish.+#+# This needs ImageMagick for the 'convert' and 'identify' tools.+#++LOGO=../../Documentation/logo.gif+LOGO_WIDTH=$(identify$LOGO|cut-d" "-f3|cut-dx-f1)+LOGO_HEIGHT=$(identify$LOGO|cut-d" "-f3|cut-dx-f2)++THROBBER=ajax-loader.gif+THROBBER_WIDTH=$(identify$THROBBER|head-1|cut-d" "-f3|\+cut-dx-f1)+THROBBER_HEIGHT=$(identify$THROBBER|head-1|cut-d" "-f3|\+cut-dx-f2)++convert-alpharemove\+-background"#ff3a40"\+$LOGO\+logo.rgb++convert-alpharemove\+-background"#ff3a40"\+$THROBBER\+throbber%02d.rgb+++makeclean+makebootsplash-packer+++# Let's put Tux in the center of an orange background.+./bootsplash-packer\+--bg_red0xff\+--bg_green0x3a\+--bg_blue0x40\+--frame_ms48\+--picture\+--pic_width$LOGO_WIDTH\+--pic_height$LOGO_HEIGHT\+--pic_position0\+--bloblogo.rgb\+--picture\+--pic_width$THROBBER_WIDTH\+--pic_height$THROBBER_HEIGHT\+--pic_position0x14\+--pic_position_offset20\+--pic_anim_type1\+--pic_anim_loop0\+--blobthrobber00.rgb\+--blobthrobber01.rgb\+--blobthrobber02.rgb\+--blobthrobber03.rgb\+--blobthrobber04.rgb\+--blobthrobber05.rgb\+--blobthrobber06.rgb\+--blobthrobber07.rgb\+--blobthrobber08.rgb\+--blobthrobber09.rgb\+--blobthrobber10.rgb\+--blobthrobber11.rgb\+bootsplash++rm*.rgb
@@ -0,0 +1,11 @@+What: /sys/devices/platform/bootsplash.0/enabled+Date: Oct 2017+KernelVersion: 4.14+Contact: Max Staudt <mstaudt@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.
@@ -0,0 +1,177 @@+==========+The Linux bootsplash+==========++:Date: November, 2017+:Author: Max Staudt <mstaudt@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˜0750++++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.+++-``struct splash_blob_header``+ (followed by payload)++ Represents one raw data stream. So far, only picture data is defined.++ The blob header is followed by a payload, then padding to n*16 bytes,+ then (if further blobs are defined in the file header) a further blob+ header.+++Alignment+---------++The bootsplash file is designed to be loaded into memory as-is.++All structures are a multiple of 16 bytes long, all elements therein are+aligned to multiples of their length, and the payloads are always padded+up to multiples of 16 bytes. This is to allow aligned accesses in all+cases while still simply mapping the structures over an in-memory copy of+the bootsplash file.+++Further information+-------------------++Please see ``drivers/video/fbdev/core/bootsplash_file.h`` for further+details and possible values in the file.++++Hooks - how the bootsplash is integrated+====================++``drivers/video/fbdev/core/fbcon.c``+``fbcon_init()`` calls ``bootsplash_init()``, which loads the default+ bootsplash file or the one specified on the kernel command line.++``fbcon_switch()`` draws the bootsplash when it's active, and is also+ one of the callers of ``set_blitting_type()``.++``set_blitting_type()`` calls ``fbcon_set_dummyops()`` when the+ bootsplash is active, overriding the text rendering functions.++``fbcon_cursor()`` will call ``bootsplash_disable()`` when an oops is+ being printed in order to make a kernel panic visible.++``drivers/video/fbdev/core/dummyblit.c``+ This contains the dummy text rendering functions used to suppress text+ output while the bootsplash is shown.++``drivers/tty/vt/keyboard.c``+``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.
From: Max Staudt <hidden> Date: 2017-12-13 19:49:54
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 <redacted>
---
.../ABI/testing/sysfs-platform-bootsplash | 32 +++++++++++++
Documentation/bootsplash.rst | 8 ++++
drivers/video/fbdev/core/bootsplash.c | 54 ++++++++++++++++++++++
3 files changed, 94 insertions(+)
@@ -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 <mstaudt@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 <mstaudt@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.
@@ -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,returncount;}+staticssize_tsplash_store_drop_splash(structdevice*device,+structdevice_attribute*attr,+constchar*buf,size_tcount)+{+structsplash_file_priv*fp;++if(!buf||!count||!splash_state.file)+returncount;++mutex_lock(&splash_state.data_lock);+fp=splash_state.file;+splash_state.file=NULL;+mutex_unlock(&splash_state.data_lock);++/* Redraw the text console */+schedule_work(&splash_state.work_redraw_vc);++bootsplash_free_file(fp);++returncount;+}++staticssize_tsplash_store_load_file(structdevice*device,+structdevice_attribute*attr,+constchar*buf,size_tcount)+{+structsplash_file_priv*fp,*fp_old;++if(!count)+return0;++fp=bootsplash_load_firmware(&splash_state.splash_device->dev,+buf);++if(!fp)+return-ENXIO;++mutex_lock(&splash_state.data_lock);+fp_old=splash_state.file;+splash_state.splash_fb=NULL;+splash_state.file=fp;+mutex_unlock(&splash_state.data_lock);++/* Update the splash or text console */+schedule_work(&splash_state.work_redraw_vc);++bootsplash_free_file(fp_old);+returncount;+}+staticDEVICE_ATTR(enabled,0644,splash_show_enabled,splash_store_enabled);+staticDEVICE_ATTR(drop_splash,0200,NULL,splash_store_drop_splash);+staticDEVICE_ATTR(load_file,0200,NULL,splash_store_load_file);staticstructattribute*splash_dev_attrs[]={&dev_attr_enabled.attr,+&dev_attr_drop_splash.attr,+&dev_attr_load_file.attr,NULL};
From: Max Staudt <hidden> Date: 2017-12-13 19:50:22
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 <redacted>
---
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(-)
@@ -53,6 +53,14 @@ static void splash_callback_redraw_vc(struct work_struct *ignored)console_unlock();}+staticvoidsplash_callback_animation(structwork_struct*ignored)+{+if(bootsplash_would_render_now()){+/* This will also re-schedule this delayed worker */+splash_callback_redraw_vc(ignored);+}+}+staticboolis_fb_compatible(conststructfb_info*info){
@@ -103,17 +111,44 @@ static bool is_fb_compatible(const struct fb_info *info)*/voidbootsplash_render_full(structfb_info*info){+boolis_update=false;+mutex_lock(&splash_state.data_lock);-if(!is_fb_compatible(info))-gotoout;+/*+*Ifwe'vepaintedonthisFBrecently,wedon'thavetodo+*thesanitychecksandbackgrounddrawingagain.+*/+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))+gotoout;++/* 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(&splash_state.dwork_animation,+msecs_to_jiffies(+splash_state.file->frame_ms));+out:mutex_unlock(&splash_state.data_lock);}
@@ -169,8 +204,14 @@ void bootsplash_enable(void)was_enabled=test_and_set_bit(0,&splash_state.enabled);-if(!was_enabled)+if(!was_enabled){+/* Force a full redraw when the splash is re-activated */+mutex_lock(&splash_state.data_lock);+splash_state.splash_fb=NULL;+mutex_unlock(&splash_state.data_lock);+schedule_work(&splash_state.work_redraw_vc);+}}
@@ -202,6 +210,7 @@ struct splash_file_priv *bootsplash_load_firmware(struct device *device,/* Walk over pictures and ensure all blob slots are filled */for(i=0;i<fp->header->num_pics;i++){structsplash_pic_priv*pp=&fp->pics[i];+conststructsplash_pic_header*ph=pp->pic_header;if(pp->blobs_loaded!=pp->pic_header->num_blobs){pr_err("Picture %u doesn't have all blob slots filled.\n",
@@ -209,8 +218,20 @@ struct splash_file_priv *bootsplash_load_firmware(struct device *device,gotoerr;}++if(ph->anim_type+&&ph->num_blobs>1+&&ph->anim_loop<pp->blobs_loaded)+have_anim=true;}+if(!have_anim)+/* Disable animation timer if there is nothing to animate */+fp->frame_ms=0;+else+/* Enforce minimum delay between frames */+fp->frame_ms=max((u16)20,fp->header->frame_ms);+pr_info("Loaded (%ld bytes, %u pics, %u blobs).\n",fw->size,fp->header->num_pics,
From: Max Staudt <hidden> Date: 2017-12-13 19:50:37
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 <redacted>
---
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
@@ -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");
@@ -15,15 +15,43 @@#include<linux/types.h>#include<linux/fb.h>+#include<linux/firmware.h>#include<linux/kernel.h>#include<linux/mutex.h>#include<linux/spinlock.h>+#include"uapi/linux/bootsplash_file.h"+/**Runtimetypes*/+structsplash_blob_priv{+structsplash_blob_header*blob_header;+constvoid*data;+};+++structsplash_pic_priv{+conststructsplash_pic_header*pic_header;++structsplash_blob_priv*blobs;+u16blobs_loaded;+};+++structsplash_file_priv{+conststructfirmware*fw;+conststructsplash_file_header*header;++structsplash_pic_priv*pics;+};++structsplash_priv{+/* Bootup and runtime state */+char*bootfile;+/**Enabled/disabledstate,tobeusedwithatomicbitoperations.*Bit0:0=Splashhidden
@@ -43,6 +71,13 @@ struct splash_priv {structplatform_device*splash_device;structwork_structwork_redraw_vc;++/* Splash data structures including lock for everything below */+structmutexdata_lock;++structfb_info*splash_fb;++structsplash_file_priv*file;};
@@ -0,0 +1,225 @@+/*+*Kernelbasedbootsplash.+*+*(Loadingandfreeingfunctions)+*+*Authors:+*MaxStaudt<mstaudt@suse.de>+*+*SPDX-License-Identifier:GPL-2.0+*/++#define pr_fmt(fmt) "bootsplash: " fmt+++#include<linux/bootsplash.h>+#include<linux/fb.h>+#include<linux/firmware.h>+#include<linux/kernel.h>+#include<linux/mutex.h>+#include<linux/printk.h>+#include<linux/types.h>+#include<linux/vmalloc.h>++#include"bootsplash_internal.h"+#include"uapi/linux/bootsplash_file.h"+++++/*+*Freeallvmalloc()'dresourcesdescribingasplashfile.+*/+voidbootsplash_free_file(structsplash_file_priv*fp)+{+if(!fp)+return;++if(fp->pics){+unsignedinti;++for(i=0;i<fp->header->num_pics;i++){+structsplash_pic_priv*pp=&fp->pics[i];++if(pp->blobs)+vfree(pp->blobs);+}++vfree(fp->pics);+}++release_firmware(fp->fw);+vfree(fp);+}+++++/*+*Loadasplashscreenfroma"firmware"file.+*+*Parsing,andsanitychecks.+*/+#ifdef __BIG_ENDIAN+#define BOOTSPLASH_MAGIC BOOTSPLASH_MAGIC_BE+#else+#define BOOTSPLASH_MAGIC BOOTSPLASH_MAGIC_LE+#endif++structsplash_file_priv*bootsplash_load_firmware(structdevice*device,+constchar*path)+{+conststructfirmware*fw;+structsplash_file_priv*fp;+unsignedinti;+constu8*walker;++if(request_firmware(&fw,path,device))+returnNULL;++if(fw->size<sizeof(structsplash_file_header)+||memcmp(fw->data,BOOTSPLASH_MAGIC,sizeof(fp->header->id))){+pr_err("Not a bootsplash file.\n");++release_firmware(fw);+returnNULL;+}++fp=vzalloc(sizeof(structsplash_file_priv));+if(!fp){+release_firmware(fw);+returnNULL;+}++pr_info("Loading splash file (%li bytes)\n",fw->size);++fp->fw=fw;+fp->header=(structsplash_file_header*)fw->data;++/* Sanity checks */+if(fp->header->version!=BOOTSPLASH_VERSION){+pr_err("Loaded v%d file, but we only support version %d\n",+fp->header->version,+BOOTSPLASH_VERSION);++gotoerr;+}++if(fw->size<sizeof(structsplash_file_header)++fp->header->num_pics+*sizeof(structsplash_pic_header)++fp->header->num_blobs+*sizeof(structsplash_blob_header)){+pr_err("File incomplete.\n");++gotoerr;+}++/* Read picture headers */+if(fp->header->num_pics){+fp->pics=vzalloc(fp->header->num_pics+*sizeof(structsplash_pic_priv));+if(!fp->pics)+gotoerr;+}++walker=fw->data+sizeof(structsplash_file_header);+for(i=0;i<fp->header->num_pics;i++){+structsplash_pic_priv*pp=&fp->pics[i];+structsplash_pic_header*ph=(void*)walker;++pr_debug("Picture %u: Size %ux%u\n",i,ph->width,ph->height);++if(ph->num_blobs<1){+pr_err("Picture %u: Zero blobs? Aborting load.\n",i);+gotoerr;+}++pp->pic_header=ph;+pp->blobs=vzalloc(ph->num_blobs+*sizeof(structsplash_blob_priv));+if(!pp->blobs)+gotoerr;++walker+=sizeof(structsplash_pic_header);+}++/* Read blob headers */+for(i=0;i<fp->header->num_blobs;i++){+structsplash_blob_header*bh=(void*)walker;+structsplash_pic_priv*pp;++if(walker+sizeof(structsplash_blob_header)+>fw->data+fw->size)+gotoerr;++walker+=sizeof(structsplash_blob_header);++if(walker+bh->length>fw->data+fw->size)+gotoerr;++if(bh->picture_id>=fp->header->num_pics)+gotonextblob;++pp=&fp->pics[bh->picture_id];++pr_debug("Blob %u, pic %u, blobs_loaded %u, num_blobs %u.\n",+i,bh->picture_id,+pp->blobs_loaded,pp->pic_header->num_blobs);++if(pp->blobs_loaded>=pp->pic_header->num_blobs)+gotonextblob;++switch(bh->type){+case0:+/* Raw 24-bit packed pixels */+if(bh->length!=pp->pic_header->width+*pp->pic_header->height*3){+pr_err("Blob %u, type 1: Length doesn't match picture.\n",+i);++gotoerr;+}+break;+default:+pr_warn("Blob %u, unknown type %u.\n",i,bh->type);+gotonextblob;+}++pp->blobs[pp->blobs_loaded].blob_header=bh;+pp->blobs[pp->blobs_loaded].data=walker;+pp->blobs_loaded++;++nextblob:+walker+=bh->length;+if(bh->length%16)+walker+=16-(bh->length%16);+}++if(walker!=fw->data+fw->size)+pr_warn("Trailing data in splash file.\n");++/* Walk over pictures and ensure all blob slots are filled */+for(i=0;i<fp->header->num_pics;i++){+structsplash_pic_priv*pp=&fp->pics[i];++if(pp->blobs_loaded!=pp->pic_header->num_blobs){+pr_err("Picture %u doesn't have all blob slots filled.\n",+i);++gotoerr;+}+}++pr_info("Loaded (%ld bytes, %u pics, %u blobs).\n",+fw->size,+fp->header->num_pics,+fp->header->num_blobs);++returnfp;+++err:+bootsplash_free_file(fp);+returnNULL;+}
@@ -91,3 +145,44 @@ void bootsplash_do_render_background(struct fb_info *info)}}}+++voidbootsplash_do_render_pictures(structfb_info*info,+conststructsplash_file_priv*fp)+{+unsignedinti;++for(i=0;i<fp->header->num_pics;i++){+structsplash_blob_priv*bp;+structsplash_pic_priv*pp=&fp->pics[i];+longdst_xoff,dst_yoff;++if(pp->blobs_loaded<1)+continue;++bp=&pp->blobs[0];++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;++if(dst_xoff<0+||dst_yoff<0+||dst_xoff+pp->pic_header->width>info->var.xres+||dst_yoff+pp->pic_header->height>info->var.yres){+pr_info_once("Picture %u is out of bounds at current resolution: %dx%d\n"+"(this will only be printed once every reboot)\n",+i,info->var.xres,info->var.yres);++continue;+}++/* Draw next splash frame */+splash_convert_to_fb(info->screen_buffer,&info->var,+info->fix.line_length,dst_xoff,dst_yoff,+bp->data,+pp->pic_header->width,pp->pic_header->height);+}+}
@@ -0,0 +1,118 @@+/*+*Kernelbasedbootsplash.+*+*(Fileformat)+*+*Authors:+*MaxStaudt<mstaudt@suse.de>+*+*SPDX-License-Identifier:GPL-2.0WITHLinux-syscall-note+*/++#ifndef __BOOTSPLASH_FILE_H+#define __BOOTSPLASH_FILE_H+++#define BOOTSPLASH_VERSION 55561+++#include<linux/kernel.h>+#include<linux/types.h>+++/*+*On-disktypes+*+*Asplashfileconsistsof:+*-Onesingle'structsplash_file_header'+*-Anarrayof'structsplash_pic_header'+*-Anarrayofrawdatablocks,eachpaddedto16bytesand+*precededbya'structsplash_blob_header'+*+*Asingle-framesplashmaylooklikethis:+*+*+--------------------++*||+*|splash_file_header|+*|->num_blobs=1|+*|->num_pics=1|+*||+*+--------------------++*||+*|splash_pic_header|+*||+*+--------------------++*||+*|splash_blob_header|+*|->type=0|+*|->picture_id=0|+*||+*|(rawRGBdata)|+*|(padto16bytes)|+*||+*+--------------------++*+*Allmulti-bytevaluesarestoredondiskinthenativeformat+*expectedbythesystemthefilewillbeusedon.+*/+#define BOOTSPLASH_MAGIC_BE "Linux bootsplash"+#define BOOTSPLASH_MAGIC_LE "hsalpstoob xuniL"++structsplash_file_header{+uint8_tid[16];/* "Linux bootsplash" (no trailing NUL) */++/* Splash file format version to avoid clashes */+uint16_tversion;++/* The background color */+uint8_tbg_red;+uint8_tbg_green;+uint8_tbg_blue;+uint8_tbg_reserved;++/*+*Numberofpic/blobssowecanallocatememoryforinternal+*structuresaheadoftimewhenreadingthefile+*/+uint16_tnum_blobs;+uint8_tnum_pics;++uint8_tpadding[103];+}__attribute__((__packed__));+++structsplash_pic_header{+uint16_twidth;+uint16_theight;++/*+*Numberofdatapackagesassociatedwiththispicture.+*Currently,theonlyuseformorethan1isforanimations.+*/+uint8_tnum_blobs;++uint8_tpadding[27];+}__attribute__((__packed__));+++structsplash_blob_header{+/* Length of the data block in bytes. */+uint32_tlength;++/*+*Typeofthecontents.+*0-RawRGBdata.+*/+uint16_ttype;++/*+*Picturethisblobisassociatedwith.+*Blobswillbeaddedtoapictureintheordertheyare+*foundinthefile.+*/+uint8_tpicture_id;++uint8_tpadding[9];+}__attribute__((__packed__));++#endif
From: Max Staudt <hidden> Date: 2017-12-13 19:50:40
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 <redacted>
Reviewed-by: Oliver Neukum <oneukum@suse.com>
---
drivers/tty/sysrq.c | 3 +++
1 file changed, 3 insertions(+)
From: Max Staudt <hidden> Date: 2017-12-13 19:50:45
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 <redacted>
---
drivers/tty/vt/keyboard.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
@@ -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();++/*+*Noreturnheresincewewanttoactually+*performtheVTswitch.+*/+}else{+if(keycode=KEY_ESC)+bootsplash_disable();++/*+*Justdropanyotherkeys.+*Theireffectwouldbehiddenbythesplash.+*/+return;+}+}+if(kbd->kbdmode=VC_MEDIUMRAW){/**Thisisextendedmediumrawmode,withkeysabove127
From: Max Staudt <hidden> Date: 2017-12-13 19:51:36
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 <redacted>
---
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
@@ -0,0 +1,294 @@+/*+*Kernelbasedbootsplash.+*+*(Mainfile:Gluecode,workers,timer,PM,kernelanduserlandAPI)+*+*Authors:+*MaxStaudt<mstaudt@suse.de>+*+*SPDX-License-Identifier:GPL-2.0+*/++#define pr_fmt(fmt) "bootsplash: " fmt+++#include<linux/atomic.h>+#include<linux/bootsplash.h>+#include<linux/console.h>+#include<linux/device.h> /* dev_warn() */+#include<linux/fb.h>+#include<linux/fs.h>+#include<linux/kernel.h>+#include<linux/jiffies.h>+#include<linux/module.h>+#include<linux/mutex.h>+#include<linux/platform_device.h>+#include<linux/printk.h>+#include<linux/selection.h> /* console_blanked */+#include<linux/stringify.h>+#include<linux/types.h>+#include<linux/vmalloc.h>+#include<linux/vt_kern.h>+#include<linux/workqueue.h>++#include"bootsplash_internal.h"+++/*+*Weonlyhaveonesplashscreen,solet'skeepasingle+*instanceoftheinternalstate.+*/+staticstructsplash_privsplash_state;+++staticvoidsplash_callback_redraw_vc(structwork_struct*ignored)+{+if(console_blanked)+return;++console_lock();+if(vc_cons[fg_console].d)+update_screen(vc_cons[fg_console].d);+console_unlock();+}+++staticboolis_fb_compatible(conststructfb_info*info)+{+if(!(info->flags&FBINFO_BE_MATH)+!=!fb_be_math((structfb_info*)info)){+dev_warn(info->device,+"Can't draw on foreign endianness framebuffer.\n");++returnfalse;+}++if(info->flags&FBINFO_MISC_TILEBLITTING){+dev_warn(info->device,+"Can't draw splash on tiling framebuffer.\n");++returnfalse;+}++if(info->fix.type!=FB_TYPE_PACKED_PIXELS+||(info->fix.visual!=FB_VISUAL_TRUECOLOR+&&info->fix.visual!=FB_VISUAL_DIRECTCOLOR)){+dev_warn(info->device,+"Can't draw splash on non-packed or non-truecolor framebuffer.\n");++dev_warn(info->device,+" type: %u visual: %u\n",+info->fix.type,info->fix.visual);++returnfalse;+}++if(info->var.bits_per_pixel!=16+&&info->var.bits_per_pixel!=24+&&info->var.bits_per_pixel!=32){+dev_warn(info->device,+"We only support drawing on framebuffers with 16, 24, or 32 bpp, not %d.\n",+info->var.bits_per_pixel);++returnfalse;+}++returntrue;+}+++/*+*Calledbyfbcon_switch()whenaninstanceisactivatedorrefreshed.+*/+voidbootsplash_render_full(structfb_info*info)+{+if(!is_fb_compatible(info))+return;++bootsplash_do_render_background(info);+}+++/*+*Externalstatusenquiryandon/offswitch+*/+boolbootsplash_would_render_now(void)+{+return!oops_in_progress+&&!console_blanked+&&bootsplash_is_enabled();+}++boolbootsplash_is_enabled(void)+{+boolwas_enabled;++/* Make sure we have the newest state */+smp_rmb();++was_enabled=test_bit(0,&splash_state.enabled);++returnwas_enabled;+}++voidbootsplash_disable(void)+{+intwas_enabled;++was_enabled=test_and_clear_bit(0,&splash_state.enabled);++if(was_enabled){+if(oops_in_progress){+/* Redraw screen now so we can see a panic */+if(vc_cons[fg_console].d)+update_screen(vc_cons[fg_console].d);+}else{+/* No urgency, redraw at next opportunity */+schedule_work(&splash_state.work_redraw_vc);+}+}+}++voidbootsplash_enable(void)+{+boolwas_enabled;++if(oops_in_progress)+return;++was_enabled=test_and_set_bit(0,&splash_state.enabled);++if(!was_enabled)+schedule_work(&splash_state.work_redraw_vc);+}+++/*+*UserlandAPIviaplatformdeviceinsysfs+*/+staticssize_tsplash_show_enabled(structdevice*dev,+structdevice_attribute*attr,char*buf)+{+returnsprintf(buf,"%d\n",bootsplash_is_enabled());+}++staticssize_tsplash_store_enabled(structdevice*device,+structdevice_attribute*attr,+constchar*buf,size_tcount)+{+boolenable;+interr;++if(!buf||!count)+return-EFAULT;++err=kstrtobool(buf,&enable);+if(err)+returnerr;++if(enable)+bootsplash_enable();+else+bootsplash_disable();++returncount;+}++staticDEVICE_ATTR(enabled,0644,splash_show_enabled,splash_store_enabled);+++staticstructattribute*splash_dev_attrs[]={+&dev_attr_enabled.attr,+NULL+};++ATTRIBUTE_GROUPS(splash_dev);+++++/*+*Powermanagementfixupviaplatformdevice+*+*Whenthesystemiswokenfromsleeporrestoredafterhibernating,we+*cannotexpectthescreencontentstostillbepresentinvideoRAM.+*Thus,wehavetoredrawthesplashifwe'recurrentlyactive.+*/+staticintsplash_resume(structdevice*device)+{+if(bootsplash_would_render_now())+schedule_work(&splash_state.work_redraw_vc);++return0;+}++staticintsplash_suspend(structdevice*device)+{+cancel_work_sync(&splash_state.work_redraw_vc);++return0;+}+++staticconststructdev_pm_opssplash_pm_ops={+.thaw=splash_resume,+.restore=splash_resume,+.resume=splash_resume,+.suspend=splash_suspend,+.freeze=splash_suspend,+};++staticstructplatform_driversplash_driver={+.driver={+.name="bootsplash",+.pm=&splash_pm_ops,+},+};+++/*+*Maininit+*/+voidbootsplash_init(void)+{+intret;++/* Initialized already? */+if(splash_state.splash_device)+return;+++/* Register platform device to export user API */+ret=platform_driver_register(&splash_driver);+if(ret){+pr_err("platform_driver_register() failed: %d\n",ret);+gotoerr;+}++splash_state.splash_device+=platform_device_alloc("bootsplash",0);++if(!splash_state.splash_device)+gotoerr_driver;++splash_state.splash_device->dev.groups=splash_dev_groups;++ret=platform_device_add(splash_state.splash_device);+if(ret){+pr_err("platform_device_add() failed: %d\n",ret);+gotoerr_device;+}+++INIT_WORK(&splash_state.work_redraw_vc,splash_callback_redraw_vc);++return;++err_device:+platform_device_put(splash_state.splash_device);+splash_state.splash_device=NULL;+err_driver:+platform_driver_unregister(&splash_driver);+err:+pr_err("Failed to initialize.\n");+}
From: Max Staudt <hidden> Date: 2017-12-13 19:51:39
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 <redacted>
Reviewed-by: Oliver Neukum <oneukum@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(+)
From: Daniel Vetter <hidden> Date: 2017-12-13 21:35:13
On Wed, Dec 13, 2017 at 08:47:45PM +0100, Max Staudt wrote:
quoted hunk
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 <redacted>
Reviewed-by: Oliver Neukum <oneukum@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(+)
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.
+ *
+ * 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 ...
-Daniel
From: Randy Dunlap <rdunlap@infradead.org> Date: 2017-12-13 23:55:47
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
From: Max Staudt <hidden> Date: 2017-12-14 15:36:55
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?
quoted
+ *
+ * A few DRM drivers' FB implementations are broken by not using
+ * deferred_io when they really should - we match on the known
+ * bad ones manually for now.
+ */
+ if (info->fbdefio
+ || !strcmp(info->fix.id, "astdrmfb")
+ || !strcmp(info->fix.id, "cirrusdrmfb")
+ || !strcmp(info->fix.id, "mgadrmfb")) {
We have a shared defio implementation now in drm_fb_helper.c, there's not
really many excuses to not fix up these drivers to just use those ...
From: Max Staudt <hidden> Date: 2017-12-14 15:37:41
On 12/14/2017 12:55 AM, Randy Dunlap wrote:
On 12/13/2017 11:47 AM, Max Staudt wrote:
quoted
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
From: Daniel Vetter <hidden> Date: 2017-12-19 12:23:22
On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
On 12/13/2017 10:35 PM, Daniel Vetter wrote:
quoted
Using drm directly would allow you to flush the contents without the fake
(and tbh, really expensive on most drivers) copy op. If you insist on
using fbdev for this stuff, then at least add a new hook to flush cpu
rendering.
My reasoning is as follows:
1) The splash screen is meant to appear as early as possible in the boot
process, and even on devices that don't have a DRM driver. For example,
an ARM box with only efifb. Thus, the choice to work on top of FB.
2) We need to go out of the way when a graphical application starts, and
come back when it's done. fbcon already has the logic for this, and
fbcon is also the thing we're trying to hide. So it seems natural to add
the splash on top of fbcon - at least for now.
And this "automatically disappear" semantics is horribly ill-defined
between fbdev and native kms. So you're not really solving a problem,
you're just not noticing the hacks because they're one layer removed (in
the fbdev emulation code).
3) I can't use DRM from the kernel, for the same reason for which there
is no "drmcon" to supplant fbcon: There is no interface to reserve
framebuffer memory from kernel space: To get memory for a framebuffer,
one needs to have a struct file that is passed through the DRM stack
down into the drivers.
On recent kernels you only need a struct drm_file, not a struct file. That
can be NULL. We've done this to make drmcon possible/easier.
If this interface existed, then there could be a generic "fb2drm"
translation layer, and we would no longer need FB compatibility code in
each KMS driver. Actually, I tried to implement this translation layer a
year ago, and hit too many walls.
We're pretty much there already I think. The reason it's not entirely gone
is that there's some nasty interactions between drm and the fbdev
emulation, and just having a pile of drivers that aren't too trivial to
convert.
I've prepared the code for a future in which fbdev no longer exists: My
sysfs interface is generically called "bootsplash", in the hope that it
will one day move on top of KMS. The hooks into fbcon are minimal and
the code is straightforward to port to KMS operations rather than FB.
But that's for another day, as far as I can see.
4) I don't fully understand what you'd like me to do. Last time I tried
to add a new entry to the fbops struct (namely fb_open_adj_file()), you
told me not to touch the framebuffer subsystem anymore, as it is meant
to die and driver developers shall use KMS instead. Have I
misunderstood?
I still don't like anyone adding features to fbdev :-)
Something like fb->flush() to finish kernel space accesses would be nice
to have, but would need to be implemented for all affected drivers
separately. The copy op hack is ugly, but solves the problem
generically.
Well, with defio being the hack it is (and because of that, a bunch of drm
drivers not really supporting it) I'm not sure things actually work better
without all this.
What shall I do?
Shall I add a new FB op for flushing when writing to the raw memory from the kernel?
As far as I can see, it would be needed for defio drivers only, is that correct?
Yes, which are kinda horrible anyway. I guess you could at least not do
all these hacks if it's not a defio driver.
-Daniel
quoted
quoted
+ *
+ * A few DRM drivers' FB implementations are broken by not using
+ * deferred_io when they really should - we match on the known
+ * bad ones manually for now.
+ */
+ if (info->fbdefio
+ || !strcmp(info->fix.id, "astdrmfb")
+ || !strcmp(info->fix.id, "cirrusdrmfb")
+ || !strcmp(info->fix.id, "mgadrmfb")) {
We have a shared defio implementation now in drm_fb_helper.c, there's not
really many excuses to not fix up these drivers to just use those ...
From: Max Staudt <hidden> Date: 2017-12-19 13:34:26
On 12/19/2017 01:23 PM, Daniel Vetter wrote:
On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
quoted
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.
quoted
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.
quoted
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 :(
quoted
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?
quoted
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.
quoted
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
quoted
quoted
quoted
+ *
+ * A few DRM drivers' FB implementations are broken by not using
+ * deferred_io when they really should - we match on the known
+ * bad ones manually for now.
+ */
+ if (info->fbdefio
+ || !strcmp(info->fix.id, "astdrmfb")
+ || !strcmp(info->fix.id, "cirrusdrmfb")
+ || !strcmp(info->fix.id, "mgadrmfb")) {
From: Daniel Vetter <hidden> Date: 2017-12-19 13:57:22
On Tue, Dec 19, 2017 at 02:34:22PM +0100, Max Staudt wrote:
On 12/19/2017 01:23 PM, Daniel Vetter wrote:
quoted
On Thu, Dec 14, 2017 at 04:36:49PM +0100, Max Staudt wrote:
quoted
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.
quoted
quoted
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.
quoted
quoted
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 :(
Where do drivers deal with struct file deep down?
quoted
quoted
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?
The problem is that defio is totally not how a real driver works. So
preferrably bootsplash would use kms directly, and use the explict dirtyfb
callback. But if you insist on using fbdev, then I think the beast course
here is to wire up a new fb_ops->flush callback.
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.
quoted
quoted
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.
Yes, so lets ignore defio and do the flushing correctly, at least for kms
drivers.
quoted
quoted
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
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).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Oliver Neukum <oneukum@suse.com> Date: 2017-12-19 14:12:39
Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
quoted
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.
Regards
Oliver
From: Max Staudt <hidden> Date: 2017-12-19 15:42:02
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.
quoted
quoted
quoted
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 */
quoted
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
From: Daniel Vetter <hidden> Date: 2017-12-19 16:03:01
On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt [off-list ref] wrote:
On 12/19/2017 02:57 PM, Daniel Vetter wrote:
quoted
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.
quoted
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.
quoted
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.
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.
quoted
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!
quoted
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.
quoted
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.
tbh I'd forget about ever touching any of the existing fbdev drivers.
Imo just not worth the time investement.
quoted
quoted
quoted
quoted
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.
quoted
else
; /* nothing */
quoted
So, what shall I do? As it is, the hack is already specific to devices that really, really need it.
Would you like me to extend the FB API or not?
Yes. Well for real I'd like you to do kms, so maybe you need to explain
why exactly you absolutely have to use fbdev (aka which driver isn't
supported by drm that you want to enable this on).
See Oliver's reply - we have plenty of fb-only systems deployed in the real world. Think Xen. Think AArch64 with efifb. Think any system before the KMS driver is loaded (which is a case that the splash is supposed to handle).
And you need a real pretty boot-splash on those? That sounds all like
servers, and I haven't yet seen a request for real pretty&fast boot
splash for servers.
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?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
From: Daniel Vetter <hidden> Date: 2017-12-19 16:09:48
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.
-Daniel
On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt [off-list ref] wrote:
On 12/19/2017 02:57 PM, Daniel Vetter wrote:
quoted
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.
quoted
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?
quoted
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.
quoted
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!
quoted
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.
quoted
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.
quoted
quoted
quoted
quoted
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.
quoted
else
; /* nothing */
quoted
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
From: Daniel Vetter <hidden> Date: 2017-12-19 16:16:38
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).
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).
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.
So, why exactly do we need this?
(let's stop the other thread meanwhile, there's no point discussing
implementation details if the why? question isn't answered yet)
Cheers, Daniel
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
From: Max Staudt <hidden> Date: 2017-12-19 16:23:57
On 12/19/2017 05:02 PM, Daniel Vetter wrote:
On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt [off-list ref] wrote:
quoted
On 12/19/2017 02:57 PM, Daniel Vetter wrote:
quoted
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!
quoted
quoted
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.
quoted
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.
quoted
quoted
quoted
So, what shall I do? As it is, the hack is already specific to devices that really, really need it.
Would you like me to extend the FB API or not?
Yes. Well for real I'd like you to do kms, so maybe you need to explain
why exactly you absolutely have to use fbdev (aka which driver isn't
supported by drm that you want to enable this on).
See Oliver's reply - we have plenty of fb-only systems deployed in the real world. Think Xen. Think AArch64 with efifb. Think any system before the KMS driver is loaded (which is a case that the splash is supposed to handle).
And you need a real pretty boot-splash on those? That sounds all like
servers, and I haven't yet seen a request for real pretty&fast boot
splash for servers.
Yeah, every little helps.
And the vesafb/efifb case is valid for all of the desktop/laptop machines as well.
quoted
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
From: Max Staudt <hidden> Date: 2017-12-19 16:26:32
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
From: Max Staudt <hidden> Date: 2017-12-19 17:04:25
On 12/19/2017 05:16 PM, Daniel Vetter wrote:
On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
quoted
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˜0750
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/374https://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)
From: Daniel Vetter <hidden> Date: 2017-12-19 17:26:46
On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt [off-list ref] wrote:
On 12/19/2017 05:16 PM, Daniel Vetter wrote:
quoted
On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
quoted
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
Aka fbdev is broken and can't actually be hotunplugged.
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.
Aka plymouth is broken.
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.
Aka more breakage.
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/374https://lkml.org/lkml/2017/11/9/324
quoted
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.
It's too big, and those folks tend to be super picky about space.
quoted
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.
quoted
So, why exactly do we need this?
For the aforementioned reasons, and to have a nice, unified bootsplash code on *all* devices.
quoted
(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.
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.
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.
Also I'm not clear at all on the "papering over races with sleeps"
part. DRM drivers shouldn't be racy when getting loaded ...
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.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
From: Max Staudt <hidden> Date: 2017-12-19 18:40:17
On 12/19/2017 06:26 PM, Daniel Vetter wrote:
On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt [off-list ref] wrote:
quoted
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
From: Ray Strode <hidden> Date: 2017-12-19 20:31:02
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.
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 ...
Why do you refer to VT_SETMODE as locking ? 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?
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...
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)
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.
2) The second is DeviceTimeout option. The point of this option is to
decide how long to wait for udev coldplug to finish. It's mostly
relevant for systems that don't have kms drivers. The point is at
somepoint during boot we need to decide to stop waiting for a drm
device to show up and just fallback to showing graphics using
legacy interfaces (like /dev/fb). We used to wait until the udev
queue went empty, but that's error prone since it gets cleared when
the root is switched. See
https://lists.freedesktop.org/archives/systemd-devel/2015-March/029184.html
So some issues are hard to fix, others are impossible to fix in userspace.
I'm not convinced there are any insurmountable problems here...
One thing i'd like to do is change boot to not map fbcon at first, and
only map it in on the fly when the user hits escape, or after boot
finishes. like, for instance, try booting with fbcon=vc:2 or
fbcon=map:9 to see how it improves the boot experience.
--Ray
From: Ray Strode <hidden> Date: 2017-12-19 21:01:47
Hi,
On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt [off-list ref] 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.
You can't do that if you're drawing all over fbcon... and it's not like multiple
monitors and 4k screens are niche these days.
--Ray
From: Daniel Vetter <hidden> Date: 2017-12-20 09:44:07
On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
On 12/19/2017 06:26 PM, Daniel Vetter wrote:
quoted
On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt [off-list ref] wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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.
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 :-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Daniel Vetter <hidden> Date: 2017-12-20 09:45:36
On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote:
On 12/19/2017 05:02 PM, Daniel Vetter wrote:
quoted
On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt [off-list ref] wrote:
quoted
On 12/19/2017 02:57 PM, Daniel Vetter wrote:
quoted
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!
Yup.
I'll leave the more fundamental discussion to the other thread on the
cover letter.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Neil Armstrong <hidden> Date: 2017-12-20 10:06:45
On 20/12/2017 10:43, Daniel Vetter wrote:
On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
quoted
On 12/19/2017 06:26 PM, Daniel Vetter wrote:
quoted
On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt [off-list ref] wrote:
quoted
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.
quoted
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.
quoted
quoted
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.
quoted
quoted
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.
quoted
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.
quoted
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 :-)
Cheers, Daniel
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....
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 !
Neil
From: Daniel Vetter <hidden> Date: 2017-12-20 10:14:33
On Wed, Dec 20, 2017 at 11:06:34AM +0100, Neil Armstrong wrote:
On 20/12/2017 10:43, Daniel Vetter wrote:
quoted
On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
quoted
On 12/19/2017 06:26 PM, Daniel Vetter wrote:
quoted
On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt [off-list ref] wrote:
quoted
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.
quoted
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.
quoted
quoted
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.
quoted
quoted
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.
quoted
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.
quoted
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 :-)
Cheers, Daniel
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....
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 !
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).
But I'm really not sold on the current integration path being anywhere
near close to a good idea long-term.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Johannes Thumshirn <hidden> Date: 2017-12-20 11:08:15
On Tue, Dec 19, 2017 at 05:16:30PM +0100, Daniel Vetter wrote:
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).
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).
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.
For _one_ reason we'd like to see this is (I was one of the requesters of this
implementation), plymouth in it's infinite wisdom also grabs the serial (IPMI)
console and escape characters in a screen log are (you can think of the rest
of this sentence yourself I think).
Also plymouth grabs the escape character of HPE iLOs, which is a serious
no-go.
But for several other reasons we can't disable $BOOTSPLASH_IMPLEMENTATION as
we're shipping a general purpose distro and don't know on what hardware it
will be installed.
This is only my peronal view on this situation.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
From: Daniel Stone <hidden> Date: 2017-12-20 11:22:43
Hi Johannes,
On 20 December 2017 at 11:08, Johannes Thumshirn [off-list ref] wrote:
On Tue, Dec 19, 2017 at 05:16:30PM +0100, Daniel Vetter wrote:
quoted
Ok I've realized that my assumptions about why you need this aren't
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).
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).
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.
For _one_ reason we'd like to see this is (I was one of the requesters of this
implementation), plymouth in it's infinite wisdom also grabs the serial (IPMI)
console and escape characters in a screen log are (you can think of the rest
of this sentence yourself I think).
You can set 'plymouth.ignore-serial-consoles' on your boot line to
disable this behaviour.
Also plymouth grabs the escape character of HPE iLOs, which is a serious
no-go.
I'm not entirely sure what this means, but maybe it's best addressed
as a bug report to the Plymouth developers? One of them is in this
thread.
Cheers,
Daniel
From: Johannes Thumshirn <hidden> Date: 2017-12-20 12:48:35
On Wed, Dec 20, 2017 at 11:22:36AM +0000, Daniel Stone wrote:
quoted
Also plymouth grabs the escape character of HPE iLOs, which is a serious
no-go.
I'm not entirely sure what this means, but maybe it's best addressed
as a bug report to the Plymouth developers? One of them is in this
thread.
Some server BMCs do have a serial port emulation which can be reached via ssh
(apart from IPMI, etc...). HPE's particular implementaion has it's escape
character bound to the Escape key. So with plymouth running, i.e. because your boot
hangs, which for me working on block, scsi and friends happens at least once a
week results in physically power cycling the machine as I can't exit the
serial emulation and go back to the BMCs shell. I don't care too much as I'm
just a developer and used to power cycle test machines, but I do care about
the customer experience in this case.
To me it looks like the plymouth folks have a slight disconnect from the
server, or non-desktop world. We've already experienced this pattern in the
world of init systems.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
From: Max Staudt <hidden> Date: 2017-12-20 13:03:27
On 12/19/2017 09:30 PM, Ray Strode wrote:
Hi,
quoted
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.
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˜0750
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.
quoted
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. <this is where Plymouth calls VT_SETMODE even though it's deactivated>
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.
quoted
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.
quoted
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 loaded after these 5 seconds have elapsed, then Plymouth will have opened /dev/fb0 and the modprobe fails.
This sleep in Plymouth, combined with DRM drivers being included in the initramfs, just happens to work around the bug on most systems.
On the other hand, what is the motivation for this delay? 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. 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 just flash for a moment. The delay only changes which systems are affected. However, if you set the delay to 0, you'll run into the bug I described above. This is a design problem, hidden by a needless delay.
2) The second is DeviceTimeout option. The point of this option is to
decide how long to wait for udev coldplug to finish. It's mostly
relevant for systems that don't have kms drivers. The point is at
somepoint during boot we need to decide to stop waiting for a drm
device to show up and just fallback to showing graphics using
legacy interfaces (like /dev/fb). We used to wait until the udev
queue went empty, but that's error prone since it gets cleared when
the root is switched. See
https://lists.freedesktop.org/archives/systemd-devel/2015-March/029184.html
I know this thread.
In the very email you linked, Tom explains that "the udev queue is empty" is NOT a way to sense that "udev coldplug is complete":
"Just to stress this again: the assumptions plymouth makes here are invalid."
In fact, there is no way to know this. DRM devices that replace generic FB devices can appear at any time. And the solution to this is to implement a timeout? This makes zero sense. It breaks with any fundamental reasoning of concurrency. As far as I can see, Plymouth doesn't understand concurrency.
So if you have a case where:
1. plymouth deactivate
2. Xorg starts
3. plymouth thinks "coldplug complete"
4. plymouth calls VT_SETMODE
...you're clearly doing something very, very wrong because you're ignoring the "deactivate" command.
If this has been truly fixed in the meantime, please ignore it.
quoted
So some issues are hard to fix, others are impossible to fix in userspace.
I'm not convinced there are any insurmountable problems here...
One thing i'd like to do is change boot to not map fbcon at first, and
only map it in on the fly when the user hits escape, or after boot
finishes. like, for instance, try booting with fbcon=vc:2 or
fbcon=map:9 to see how it improves the boot experience.
This doesn't touch upon any of the problems that I've described, and only serves to introduce additional failure points.
The reason why I wrote the kernel splash is that it's foolproof.
It doesn't need these hacks that just keep piling up.
No sleeps. No remapping of consoles. No races. No fights. No nothing.
This is why I started it.
Max
From: Max Staudt <hidden> Date: 2017-12-20 13:14:38
On 12/19/2017 10:01 PM, Ray Strode wrote:
Hi,
On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt [off-list ref] wrote:
quoted
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
From: Max Staudt <hidden> Date: 2017-12-20 14:10:59
On 12/20/2017 10:43 AM, Daniel Vetter wrote:
On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
quoted
On 12/19/2017 06:26 PM, Daniel Vetter wrote:
quoted
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 ;)
quoted
quoted
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?
quoted
quoted
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.
quoted
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...
From: Max Staudt <hidden> Date: 2017-12-20 14:16:32
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
From: Max Staudt <hidden> Date: 2017-12-20 14:55:32
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
From: Daniel Vetter <hidden> Date: 2017-12-20 15:11:54
On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt [off-list ref] wrote:
On 12/20/2017 11:14 AM, Daniel Vetter wrote:
quoted
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.
-Daniel
quoted
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).
From: Daniel Vetter <hidden> Date: 2017-12-20 15:19:05
On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter [off-list ref] wrote:
On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt [off-list ref] wrote:
quoted
On 12/20/2017 11:14 AM, Daniel Vetter wrote:
quoted
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 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.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
From: Ray Strode <hidden> Date: 2017-12-20 15:22:21
Hi,
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
So the thing to realize is, that using /dev/fb is a last ditch effort
by plymouth to make
things work. It's basically a compat hack to keep vga=0x318 working
and also a nod
to embedded systems that just have /dev/fb and don't have a kms driver. If we
fall back to /dev/fb we lose, as mentioned before, multi-monitor
support. And it's a
legacy, deprecated api.
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 ?
If you have a better way of calling it, I'd be glad to learn.
Maybe "grabbing the VT", "taking ownership of the VT", ...?
I don't care what we call it, I just didn't understand what you were
saying before.
I think i'd say "manages vt switching", but whatever.
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.
[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.
(though it should use drm subsystem apis not graphics subsystem apis,
/dev/fb is going
the way of the dodo)
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.
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.
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 just flash for a moment.
again, we don't blink the splash on and off. we have transition animations.
The delay only changes which systems are affected. However, if you set the delay to 0,
you'll run into the bug I described above.
Then put the drm driver in the initramfs so you fix your bug !
This is a design problem, hidden by a needless delay.
From: Daniel Vetter <hidden> Date: 2017-12-20 15:22:30
On Wed, Dec 20, 2017 at 4:19 PM, Daniel Vetter [off-list ref] wrote:
On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter [off-list ref] wrote:
quoted
On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt [off-list ref] wrote:
quoted
On 12/20/2017 11:14 AM, Daniel Vetter wrote:
quoted
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 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.
*replacement for efifb/vesafb in the form of simpledrm. The
in-userspace fbcon is called kmscon, so also exists already. The
emergency boot splash thing was called drmlog iirc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
From: Ray Strode <hidden> Date: 2017-12-20 15:36:20
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?
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.
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.
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...
--Ray
From: Max Staudt <hidden> Date: 2017-12-20 16:15:52
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
From: Max Staudt <hidden> Date: 2017-12-20 16:23:33
On 12/20/2017 04:19 PM, Daniel Vetter wrote:
On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter [off-list ref] wrote:
quoted
On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt [off-list ref] wrote:
quoted
On 12/20/2017 11:14 AM, Daniel Vetter wrote:
quoted
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
From: Max Staudt <hidden> Date: 2017-12-20 16:44:37
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.
quoted
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.
quoted
[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.
quoted
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.
quoted
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.
quoted
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.
quoted
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 just flash for a moment.
again, we don't blink the splash on and off. we have transition animations.
quoted
The delay only changes which systems are affected. However, if you set the delay to 0,
you'll run into the bug I described above.
Then put the drm driver in the initramfs so you fix your bug !
quoted
This is a design problem, hidden by a needless delay.
really don't see how it is.
Ah, I see. I admit I wasn't aware of such transitions and boot timings.
So let's take SUSE. They don't have a finishing transition, the splash simply stops and is hidden at once.
Such a splash makes sense to be shown instantly, right?
So the startup delay could be reduced to 0. Except that that would mean running into the initrd "bug".
Max
From: Max Staudt <hidden> Date: 2017-12-20 16:52:24
On 12/20/2017 04:35 PM, Ray Strode wrote:
Hi,
quoted
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.
quoted
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.
quoted
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.
quoted
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
From: Daniel Vetter <hidden> Date: 2017-12-21 09:48:11
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.
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
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.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Ray Strode <hidden> Date: 2017-12-21 14:52:09
Hi,
On Wed, Dec 20, 2017 at 11:44 AM Max Staudt [off-list ref] 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.
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.
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.
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).
But if you do 2) then it's not unreasonable if things break with new
hardware. 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), 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.
But the easy answer is to just fix the initrd to have the graphics drivers.
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.
Right, ideally boot splash problems should never stop boot from proceeding.
So let's take SUSE. They don't have a finishing transition, the splash simply stops
and is hidden at once. Such a splash makes sense to be shown instantly, right?
I don't think it makes sense for animations to lack transitions.
animations without
transitions look buggy or unfinished. they should fade out or finish
the loop, or
whatever. If it's a static image it should fade to black or the
background color.
(going to be away from the computer for a few days after this message
so probably won't reply for a while to further discussion)
--Ray
From: Max Staudt <hidden> Date: 2017-12-21 16:32:47
On 12/21/2017 03:51 PM, Ray Strode wrote:
Hi,
On Wed, Dec 20, 2017 at 11:44 AM Max Staudt [off-list ref] wrote:
quoted
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.
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!
quoted
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.
quoted
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 splash in as many cases as possible. If you boot your Fedora machine in a framebuffer mode, or in EFI mode, you'll unleash these issues.
quoted
So let's take SUSE. They don't have a finishing transition, the splash simply stops
and is hidden at once. Such a splash makes sense to be shown instantly, right?
I don't think it makes sense for animations to lack transitions.
animations without
transitions look buggy or unfinished. they should fade out or finish
the loop, or
whatever. If it's a static image it should fade to black or the
background color.
Umm... yeah, that's a design decision. I'm afraid that's not my department ;)
What about the delay? Do you agree that with such a simple, no-transition splash, it makes sense to reduce the delay to 0?
(going to be away from the computer for a few days after this message
so probably won't reply for a while to further discussion)
Yes, me too. I'll be back in 2018.
Thank you for your feedback and for fixing Plymouth!
Max
From: Max Staudt <hidden> Date: 2017-12-21 16:52:05
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
From: Jani Nikula <jani.nikula@linux.intel.com> Date: 2017-12-29 17:13:47
On Tue, 19 Dec 2017, Daniel Vetter [off-list ref] wrote:
On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote:
quoted
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).
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).
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.
So, why exactly do we need this?
Okay, I'll take another step back from the implementation and most of
the discussion here, and look at what *I* would like to see on screen
when I have my user hat on and my kernel developer hat securely stowed
away.
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.
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.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Tue, 19 Dec 2017 19:40:12 +0100
Max Staudt [off-list ref] wrote:
On 12/19/2017 06:26 PM, Daniel Vetter wrote:
quoted
On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt [off-list ref] wrote:
quoted
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.
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.
quoted
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.
Alan
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.
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.
Probably no console or tty layer even present, no keyboard drivers, no
mouse.
Alan
On Tue, 19 Dec 2017 15:07:53 +0100
Oliver Neukum [off-list ref] wrote:
Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
quoted
quoted
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 ?
Alan
From: Max Staudt <hidden> Date: 2018-01-03 17:38:51
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
From: Max Staudt <hidden> Date: 2018-01-03 17:56:35
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.
quoted
quoted
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
From: Max Staudt <hidden> Date: 2018-01-03 18:00:47
On 12/31/2017 01:44 PM, Alan Cox wrote:
quoted
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
From: Max Staudt <hidden> Date: 2018-01-03 18:04:47
On 12/31/2017 01:53 PM, Alan Cox wrote:
On Tue, 19 Dec 2017 15:07:53 +0100
Oliver Neukum [off-list ref] wrote:
quoted
Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
quoted
quoted
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