Hi!
Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
taken from suse kernel. I'll probably try to modify it to work with
radeonfb.
Any ideas why bootsplash needs to hack into vesafb? It only uses
vesafb_ops to test against them before some kind of free...
Pavel
--- clean/drivers/char/keyboard.c 2005-01-22 21:24:52.000000000 +0100
+++ linux-suse/drivers/char/keyboard.c 2005-02-18 16:13:06.000000000 +0100
@@ -1058,6 +1058,15 @@
if (keycode < BTN_MISC)
printk(KERN_WARNING "keyboard.c: can't emulate rawmode for keycode %d\n", keycode);
+#ifdef CONFIG_BOOTSPLASH
+ /* This code has to be redone for some non-x86 platforms */
+ if (down == 1 && (keycode == 0x3c || keycode == 0x01)) { /* F2 and ESC on PC keyboard */
+ extern int splash_verbose(void);
+ if (splash_verbose())
+ return;
+ }
+#endif
+
#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
if (keycode == KEY_SYSRQ && (sysrq_down || (down == 1 && sysrq_alt))) {
sysrq_down = down;
--- clean/drivers/char/n_tty.c 2005-02-03 22:27:12.000000000 +0100
+++ linux-suse/drivers/char/n_tty.c 2005-02-18 16:13:06.000000000 +0100
@@ -1299,6 +1299,15 @@
tty->minimum_to_wake = (minimum - (b - buf));
if (!input_available_p(tty, 0)) {
+#ifdef CONFIG_BOOTSPLASH
+ if (file->f_dentry->d_inode->i_rdev == MKDEV(TTY_MAJOR,0) ||
+ file->f_dentry->d_inode->i_rdev == MKDEV(TTY_MAJOR,1) ||
+ file->f_dentry->d_inode->i_rdev == MKDEV(TTYAUX_MAJOR,0) ||
+ file->f_dentry->d_inode->i_rdev == MKDEV(TTYAUX_MAJOR,1)) {
+ extern int splash_verbose(void);
+ (void)splash_verbose();
+ }
+#endif
if (test_bit(TTY_OTHER_CLOSED, &tty->flags)) {
retval = -EIO;
break;
--- clean/drivers/char/vt.c 2005-01-12 11:07:39.000000000 +0100
+++ linux-suse/drivers/char/vt.c 2005-02-18 16:13:06.000000000 +0100
@@ -3251,6 +3251,31 @@
return 0;
}
+#ifdef CONFIG_BOOTSPLASH
+void con_remap_def_color(int currcons, int new_color)
+{
+ unsigned short *sbuf = screenbuf;
+ unsigned c, len = screenbuf_size >> 1;
+ int old_color;
+
+ if (sbuf) {
+ old_color = def_color << 8;
+ new_color <<= 8;
+ while(len--) {
+ c = *sbuf;
+ if (((c ^ old_color) & 0xf000) == 0)
+ *sbuf ^= (old_color ^ new_color) & 0xf000;
+ if (((c ^ old_color) & 0x0f00) == 0)
+ *sbuf ^= (old_color ^ new_color) & 0x0f00;
+ sbuf++;
+ }
+ new_color >>= 8;
+ }
+ def_color = color = new_color;
+ update_attr(currcons);
+}
+#endif
+
/*
* Visible symbols for modules
*/
--- clean/drivers/video/Kconfig 2005-02-03 22:27:18.000000000 +0100
+++ linux-suse/drivers/video/Kconfig 2005-02-18 16:13:06.000000000 +0100
@@ -1140,5 +1140,9 @@
source "drivers/video/backlight/Kconfig"
endif
+if FB
+ source "drivers/video/bootsplash/Kconfig"
+endif
+
endmenu
--- clean/drivers/video/Makefile 2005-02-03 22:27:18.000000000 +0100
+++ linux-suse/drivers/video/Makefile 2005-02-18 16:13:06.000000000 +0100
@@ -7,6 +7,7 @@
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
obj-$(CONFIG_SYSFS) += backlight/
+obj-$(CONFIG_BOOTSPLASH) += bootsplash/
obj-$(CONFIG_FB) += fbmem.o fbmon.o fbcmap.o fbsysfs.o modedb.o softcursor.o
# Only include macmodes.o if we have FB support and are PPC
--- clean/drivers/video/console/bitblit.c 2004-12-25 13:35:01.000000000 +0100
+++ linux-suse/drivers/video/console/bitblit.c 2005-02-18 16:13:06.000000000 +0100
@@ -18,6 +18,9 @@
#include <linux/console.h>
#include <asm/types.h>
#include "fbcon.h"
+#ifdef CONFIG_BOOTSPLASH
+#include "../bootsplash/bootsplash.h"
+#endif
/*
* Accelerated handlers.
@@ -77,6 +80,13 @@
{
struct fb_copyarea area;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data) {
+ splash_bmove(info->splash_data, vc, info,
+ sy, sx, dy, dx, height, width);
+ return;
+ }
+#endif
area.sx = sx * vc->vc_font.width;
area.sy = sy * vc->vc_font.height;
area.dx = dx * vc->vc_font.width;
@@ -93,6 +103,13 @@
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
struct fb_fillrect region;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data) {
+ splash_clear(info->splash_data, vc, info,
+ sy, sx, height, width);
+ return;
+ }
+#endif
region.color = attr_bgcol_ec(bgshift, vc);
region.dx = sx * vc->vc_font.width;
region.dy = sy * vc->vc_font.height;
@@ -127,6 +144,13 @@
struct fb_image image;
u8 *src, *dst, *buf = NULL;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data) {
+ splash_putcs(info->splash_data, vc, info, s, count, yy, xx);
+ return;
+ }
+#endif
+
if (attribute) {
buf = kmalloc(cellsize, GFP_KERNEL);
if (!buf)
@@ -215,6 +239,13 @@
unsigned int bs = info->var.yres - bh;
struct fb_fillrect region;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data) {
+ splash_clear_margins(info->splash_data, vc, info, bottom_only);
+ return;
+ }
+#endif
+
region.color = attr_bgcol_ec(bgshift, vc);
region.rop = ROP_COPY;
@@ -373,6 +404,13 @@
cursor.image.depth = 1;
cursor.rop = ROP_XOR;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data) {
+ splash_cursor(info->splash_data, info, &cursor);
+ ops->cursor_reset = 0;
+ return;
+ }
+#endif
info->fbops->fb_cursor(info, &cursor);
ops->cursor_reset = 0;
--- clean/drivers/video/console/fbcon.c 2005-02-03 22:27:18.000000000 +0100
+++ linux-suse/drivers/video/console/fbcon.c 2005-02-18 16:13:06.000000000 +0100
@@ -93,6 +93,9 @@
#endif
#include "fbcon.h"
+#ifdef CONFIG_BOOTSPLASH
+#include "../bootsplash/bootsplash.h"
+#endif
#ifdef FBCONDEBUG
# define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ , ## args)
@@ -395,6 +398,10 @@
for (i = first_fb_vc; i <= last_fb_vc; i++)
con2fb_map[i] = info_idx;
+#ifdef CONFIG_BOOTSPLASH
+ splash_init();
+#endif
+
err = take_over_console(&fb_con, first_fb_vc, last_fb_vc,
fbcon_is_default);
if (err) {
@@ -937,6 +944,16 @@
rows = vc->vc_rows;
new_cols = info->var.xres / vc->vc_font.width;
new_rows = info->var.yres / vc->vc_font.height;
+
+#ifdef CONFIG_BOOTSPLASH
+ if (vc->vc_splash_data && vc->vc_splash_data->splash_state) {
+ new_cols = vc->vc_splash_data->splash_text_wi / vc->vc_font.width;
+ new_rows = vc->vc_splash_data->splash_text_he / vc->vc_font.height;
+ logo = 0;
+ con_remap_def_color(vc->vc_num, vc->vc_splash_data->splash_color << 4 | vc->vc_splash_data->splash_fg_color);
+ }
+#endif
+
vc_resize(vc->vc_num, new_cols, new_rows);
/*
* We must always set the mode. The mode of the previous console
@@ -1562,6 +1579,10 @@
fbcon_softback_note(vc, t, count);
if (logo_shown >= 0)
goto redraw_up;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data)
+ goto redraw_up;
+#endif
switch (p->scrollmode) {
case SCROLL_MOVE:
ops->bmove(vc, info, t + count, 0, t, 0,
@@ -1646,6 +1667,10 @@
case SM_DOWN:
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data)
+ goto redraw_down;
+#endif
switch (p->scrollmode) {
case SCROLL_MOVE:
ops->bmove(vc, info, t, 0, t + count, 0,
@@ -1788,6 +1813,14 @@
}
return;
}
+
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data && sy == dy && height == 1) {
+ /* must use slower redraw bmove to keep background pic intact */
+ splash_bmove_redraw(info->splash_data, vc, info, sy, sx, dx, width);
+ return;
+ }
+#endif
ops->bmove(vc, info, real_y(p, sy), sx, real_y(p, dy), dx,
height, width);
}
@@ -1890,6 +1923,10 @@
info = registered_fb[con2fb_map[vc->vc_num]];
+#ifdef CONFIG_BOOTSPLASH
+ splash_prepare(vc, info);
+#endif
+
if (softback_top) {
int l = fbcon_softback_size / vc->vc_size_row;
if (softback_lines)
@@ -1999,6 +2036,12 @@
static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info,
int blank)
{
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data) {
+ splash_blank(info->splash_data, vc, info, blank);
+ return;
+ }
+#endif
if (blank) {
unsigned short charmask = vc->vc_hi_font_mask ?
0x1ff : 0xff;
@@ -2196,8 +2239,15 @@
}
if (resize) {
+ u32 xres = info->var.xres, yres = info->var.yres;
/* reset wrap/pan */
info->var.xoffset = info->var.yoffset = p->yscroll = 0;
+#ifdef CONFIG_BOOTSPLASH
+ if (info->splash_data) {
+ xres = info->splash_data->splash_text_wi;
+ yres = info->splash_data->splash_text_he;
+ }
+#endif
vc_resize(vc->vc_num, info->var.xres / w, info->var.yres / h);
if (CON_IS_VISIBLE(vc) && softback_buf) {
int l = fbcon_softback_size / vc->vc_size_row;
--- clean/drivers/video/console/fbcon.h 2005-01-22 21:24:52.000000000 +0100
+++ linux-suse/drivers/video/console/fbcon.h 2005-02-18 16:13:06.000000000 +0100
@@ -23,6 +23,34 @@
* low-level frame buffer device
*/
+#ifdef CONFIG_BOOTSPLASH
+struct splash_data {
+ int splash_state; /* show splash? */
+ int splash_color; /* transparent color */
+ int splash_fg_color; /* foreground color */
+ int splash_width; /* width of image */
+ int splash_height; /* height of image */
+ int splash_text_xo; /* text area origin */
+ int splash_text_yo;
+ int splash_text_wi; /* text area size */
+ int splash_text_he;
+ int splash_showtext; /* silent/verbose mode */
+ int splash_boxcount;
+ int splash_percent;
+ int splash_overpaintok; /* is it ok to overpaint boxes */
+ int splash_palcnt;
+ char *oldscreen_base; /* pointer to top of virtual screen */
+ unsigned char *splash_boxes;
+ unsigned char *splash_jpeg; /* jpeg */
+ unsigned char *splash_palette; /* palette for 8-bit */
+
+ int splash_dosilent; /* show silent jpeg */
+ unsigned char *splash_silentjpeg;
+ unsigned char *splash_sboxes;
+ int splash_sboxcount;
+};
+#endif
+
struct display {
/* Filled in by the frame buffer device */
u_short inverse; /* != 0 text black on white as default */
--- clean/drivers/video/vesafb.c 2005-02-03 22:27:19.000000000 +0100
+++ linux-suse/drivers/video/vesafb.c 2005-02-18 16:13:06.000000000 +0100
@@ -175,7 +175,10 @@
return 0;
}
-static struct fb_ops vesafb_ops = {
+#ifndef CONFIG_BOOTSPLASH
+static
+#endif
+struct fb_ops vesafb_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = vesafb_setcolreg,
.fb_pan_display = vesafb_pan_display,
@@ -260,6 +263,9 @@
* option to simply use size_total as that
* wastes plenty of kernel address space. */
size_remap = size_vmode * 2;
+#ifdef CONFIG_BOOTSPLASH
+ size_remap *= 2; /* some more for the images */
+#endif
if (vram_remap)
size_remap = vram_remap * 1024 * 1024;
if (size_remap < size_vmode)
Only in linux-suse/include/asm-i386: asm_offsets.h
--- clean/include/linux/console_struct.h 2005-01-12 11:07:40.000000000 +0100
+++ linux-suse/include/linux/console_struct.h 2005-02-18 16:13:06.000000000 +0100
@@ -89,6 +89,9 @@
struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */
unsigned long vc_uni_pagedir;
unsigned long *vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
+#ifdef CONFIG_BOOTSPLASH
+ struct splash_data *vc_splash_data;
+#endif
struct vt_struct *vc_vt;
/* additional information is in vt_kern.h */
};
--- clean/include/linux/fb.h 2005-01-22 21:24:53.000000000 +0100
+++ linux-suse/include/linux/fb.h 2005-02-18 16:13:06.000000000 +0100
@@ -726,6 +726,14 @@
void *fbcon_par; /* fbcon use-only private area */
/* From here on everything is device dependent */
void *par;
+#ifdef CONFIG_BOOTSPLASH
+ struct splash_data *splash_data;
+ unsigned char *splash_pic;
+ int splash_pic_size;
+ int splash_bytes;
+ char *silent_screen_base; /* real screen base */
+ char fb_cursordata[64];
+#endif
};
#ifdef MODULE
Only in linux-suse/kernel: config_data.gz
--- clean/kernel/power/swsusp.c 2005-01-22 21:24:53.000000000 +0100
+++ linux-suse/kernel/power/swsusp.c 2005-02-18 16:13:20.000000000 +0100
@@ -1204,6 +1204,14 @@
return error;
if ((error = check_header()))
return error;
+
+#ifdef CONFIG_BOOTSPLASH
+ {
+ extern int splash_verbose(void);
+ (void)splash_verbose();
+ }
+#endif
+
if ((error = read_pagedir()))
return error;
if ((error = data_read()))
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Fri, Feb 18, 2005 at 05:52:54PM +0100, Pavel Machek wrote:
Hi,
> Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
> taken from suse kernel. I'll probably try to modify it to work with
> radeonfb.
>
> Any ideas why bootsplash needs to hack into vesafb? It only uses
> vesafb_ops to test against them before some kind of free...
It doesn't really need vesafb for anything. Back in the days of 2.6.7
I used to release a version of bootsplash that had the dep. on vesafb
removed. It worked fine with at least some other fb drivers.
You might also want to save yourself some work and try out an
alternative solution called fbsplash [1], which I designed after I got
tired of fixing bootsplash and which I actively maintain. Fbsplash
provides virtually the same functionality, and it has as much code as
possible moved into userspace (no more JPEG decoders in the kernel).
[1] http://dev.gentoo.org/~spock/projects/gensplash/current/
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl
On Sat, Feb 19, 2005 at 02:14:34AM +0100, Michal Januszewski wrote:
> On Fri, Feb 18, 2005 at 05:52:54PM +0100, Pavel Machek wrote:
>
> Hi,
>
> > Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
> > taken from suse kernel. I'll probably try to modify it to work with
> > radeonfb.
> >
> > Any ideas why bootsplash needs to hack into vesafb? It only uses
> > vesafb_ops to test against them before some kind of free...
>
> It doesn't really need vesafb for anything. Back in the days of 2.6.7
> I used to release a version of bootsplash that had the dep. on vesafb
> removed. It worked fine with at least some other fb drivers.
>
> You might also want to save yourself some work and try out an
> alternative solution called fbsplash [1], which I designed after I got
> tired of fixing bootsplash and which I actively maintain. Fbsplash
> provides virtually the same functionality, and it has as much code as
> possible moved into userspace (no more JPEG decoders in the kernel).
>
> [1] http://dev.gentoo.org/~spock/projects/gensplash/current/
Pavel, I agree with Michal, take a look at this version of the code
instead of the version that you posted. It's a _whole_ lot more sane,
and possibly even mergable.
Michal, any thoughts on submitting it for inclusion? It seems pretty
stable now.
thanks,
greg k-h
Hi!
> > > Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
> > > taken from suse kernel. I'll probably try to modify it to work with
> > > radeonfb.
> > >
> > > Any ideas why bootsplash needs to hack into vesafb? It only uses
> > > vesafb_ops to test against them before some kind of free...
> >
> > It doesn't really need vesafb for anything. Back in the days of 2.6.7
> > I used to release a version of bootsplash that had the dep. on vesafb
> > removed. It worked fine with at least some other fb drivers.
> >
> > You might also want to save yourself some work and try out an
> > alternative solution called fbsplash [1], which I designed after I got
> > tired of fixing bootsplash and which I actively maintain. Fbsplash
> > provides virtually the same functionality, and it has as much code as
> > possible moved into userspace (no more JPEG decoders in the kernel).
> >
> > [1] http://dev.gentoo.org/~spock/projects/gensplash/current/
>
> Pavel, I agree with Michal, take a look at this version of the code
> instead of the version that you posted. It's a _whole_ lot more sane,
> and possibly even mergable.
Yes, I agree, almost anything is more sane than code I posted :-(. My
only requirement is that it works with radeonfb and similar low-level
drivers (so that I can get suspend-to-ram to work) and that it gets
past our branding people...
> Michal, any thoughts on submitting it for inclusion? It seems pretty
> stable now.
How many distros do use some variant of bootsplash? SuSE does, from
above url I guess gentoo does, too... Does RedHat do something
similar? [Or do they just set log-level to very high giving them clean
look?] What about Debian?
If most distros do some kind of splash screen, anyway, it would make
sense to merge one "good" version...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
> How many distros do use some variant of bootsplash? SuSE does, from
> above url I guess gentoo does, too... Does Red Hat do something
> similar? [Or do they just set log-level to very high giving them clean
> look?] What about Debian?
Red Hat/Fedora uses "quiet" boot option, plus a userspace early graphic
On Sat, Feb 19, 2005 at 03:03:26PM -0800, Greg KH wrote:
> Pavel, I agree with Michal, take a look at this version of the code
> instead of the version that you posted. It's a _whole_ lot more sane,
> and possibly even mergable.
>
> Michal, any thoughts on submitting it for inclusion? It seems pretty
> stable now.
It is pretty stable indeed, I haven't had any major bug reports for
quite some time now. It's probably as ready as it's ever going to be.
So the question is: what should I do with it? Who do I send it to?
Also, if anyone has comments about the code, bug reports, etc. - feel
free to contact me. If there are any issues remaining, I'd like to fix
them ASAP.
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl
On Sun, Feb 20, 2005 at 12:25:19AM +0100, Pavel Machek wrote:
Hi,
> Yes, I agree, almost anything is more sane than code I posted :-(. My
> only requirement is that it works with radeonfb and similar low-level
> drivers (so that I can get suspend-to-ram to work) and that it gets
> past our branding people...
I don't know about the branding people, but suspend-to-ram and radeonfb
shouldn't be a problem for fbsplash :)
> How many distros do use some variant of bootsplash? SuSE does, from
> above url I guess gentoo does, too... Does RedHat do something
> similar? [Or do they just set log-level to very high giving them clean
> look?] What about Debian?
As far as I know: SuSE uses bootsplash, Gentoo and PLD use fbsplash,
RedHat uses rhgb (100% userspace solution, based on xvesa, doesn't
provide graphical backgrounds on vt's - for that a kernel patch like
bootsplash or fbsplash is necessary). I don't know about Debian - they
probably have some (possibly unofficial) support for both bootsplash
and fbsplash.
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 20 Feb 2005, Michal Januszewski wrote:
> On Sun, Feb 20, 2005 at 12:25:19AM +0100, Pavel Machek wrote:
>
>> How many distros do use some variant of bootsplash? SuSE does, from
>> above url I guess gentoo does, too... Does RedHat do something
>> similar? [Or do they just set log-level to very high giving them clean
>> look?] What about Debian?
>
> As far as I know: SuSE uses bootsplash, Gentoo and PLD use fbsplash,
> RedHat uses rhgb (100% userspace solution, based on xvesa, doesn't
> provide graphical backgrounds on vt's - for that a kernel patch like
> bootsplash or fbsplash is necessary). I don't know about Debian - they
> probably have some (possibly unofficial) support for both bootsplash
> and fbsplash.
Indeed, there is bootsplash and fbsplash for Debian, but only unofficial
packages.
Marcos Marado
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFCGUFmmNlq8m+oD34RAtbqAJ43WanT3YNwRy8bkUIbrIqCl8u1mgCggy6R
4jZqOJQoO3vCeBe/fE/WUhk=
=CFlt
-----END PGP SIGNATURE-----
On Sun, Feb 20, 2005 at 02:15:05PM +0100, Michal Januszewski wrote:
> On Sat, Feb 19, 2005 at 03:03:26PM -0800, Greg KH wrote:
>
> > Pavel, I agree with Michal, take a look at this version of the code
> > instead of the version that you posted. It's a _whole_ lot more sane,
> > and possibly even mergable.
> >
> > Michal, any thoughts on submitting it for inclusion? It seems pretty
> > stable now.
>
> It is pretty stable indeed, I haven't had any major bug reports for
> quite some time now. It's probably as ready as it's ever going to be.
> So the question is: what should I do with it? Who do I send it to?
As per Documentation/SubmittingPatches, you take the patch, split it up
into logic parts, and post it here at lkml, with a Signed-off-by: line
and a good ChangeLog description in each email.
We can take it from there...
thanks,
greg k-h
Hi!
> > Yes, I agree, almost anything is more sane than code I posted :-(. My
> > only requirement is that it works with radeonfb and similar low-level
> > drivers (so that I can get suspend-to-ram to work) and that it gets
> > past our branding people...
>
> I don't know about the branding people, but suspend-to-ram and radeonfb
> shouldn't be a problem for fbsplash :)
>
> > How many distros do use some variant of bootsplash? SuSE does, from
> > above url I guess gentoo does, too... Does RedHat do something
> > similar? [Or do they just set log-level to very high giving them clean
> > look?] What about Debian?
>
> As far as I know: SuSE uses bootsplash, Gentoo and PLD use fbsplash,
> RedHat uses rhgb (100% userspace solution, based on xvesa, doesn't
> provide graphical backgrounds on vt's - for that a kernel patch like
> bootsplash or fbsplash is necessary). I don't know about Debian - they
> probably have some (possibly unofficial) support for both bootsplash
> and fbsplash.
Well, I like rhgb the best (because it is 100% userspace and I do not
have to deal with it :-), but it seems like bootsplash should be
deprecated in favor of fbsplash.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
> Well, I like rhgb the best (because it is 100% userspace and I do not
> have to deal with it :-), but it seems like bootsplash should be
> deprecated in favor of fbsplash.
well.. how much does it really need in kernel space? I mean, with all
drivers as modules, and the "quiet" option, initramfs runs *really*
fast. And that can just bang a bitmap to the framebuffer as first
thing... (rhgb does it a bit later but that's a design choice in a
feature vs early-boot tradeoff).
Hi!
> > Well, I like rhgb the best (because it is 100% userspace and I do not
> > have to deal with it :-), but it seems like bootsplash should be
> > deprecated in favor of fbsplash.
>
> well.. how much does it really need in kernel space? I mean, with all
> drivers as modules, and the "quiet" option, initramfs runs *really*
> fast. And that can just bang a bitmap to the framebuffer as first
> thing... (rhgb does it a bit later but that's a design choice in a
> feature vs early-boot tradeoff).
[aj added to the list].
Andreas, who is the person to talk about this? I like redhat's
solution the best. Pass "quiet", perhaps replace penguin with some big
picture including penguin and chameleon or something, and do the
interesting work in userspace...
That's the best solution, technically... Perhaps it is even acceptable
politically?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Sun, Feb 27, 2005 at 08:31:39PM +0100, Arjan van de Ven wrote:
> well.. how much does it really need in kernel space? I mean, with all
> drivers as modules, and the "quiet" option, initramfs runs *really*
> fast. And that can just bang a bitmap to the framebuffer as first
> thing... (rhgb does it a bit later but that's a design choice in a
> feature vs early-boot tradeoff).
Most of the code in fbsplash handles the so-called 'verbose' mode,
ie. displaying a pretty picture in the background of the consoles.
The 'silent' mode (progress bar and stuff) can be brought down to
a single call to a userspace helper which can paint the initial bitmap
or do whatever else it wants to do. In fact, this is how it works now.
However, fbsplash currently not only calls the helper, but also tracks
whether we're running in the 'silent' mode or in the 'verbose' mode.
I plan to remove that functionality, so we'll be left with the
following:
- silent is handled 100% by userspace
- verbose is handled by fbsplash (ie. kernelspace)
- fbsplash takes care of the initial call to the userspace
helper when starting in the silent mode (splash=silent in
the kernel command line)
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl
On Sun, Feb 27, 2005 at 08:52:06PM +0100, Michal Januszewski wrote:
> On Sun, Feb 27, 2005 at 08:31:39PM +0100, Arjan van de Ven wrote:
>
> > well.. how much does it really need in kernel space? I mean, with all
> > drivers as modules, and the "quiet" option, initramfs runs *really*
> > fast. And that can just bang a bitmap to the framebuffer as first
> > thing... (rhgb does it a bit later but that's a design choice in a
> > feature vs early-boot tradeoff).
>
> Most of the code in fbsplash handles the so-called 'verbose' mode,
> ie. displaying a pretty picture in the background of the consoles.
> The 'silent' mode (progress bar and stuff) can be brought down to
> a single call to a userspace helper which can paint the initial bitmap
> or do whatever else it wants to do. In fact, this is how it works now.
> However, fbsplash currently not only calls the helper, but also tracks
> whether we're running in the 'silent' mode or in the 'verbose' mode.
> I plan to remove that functionality, so we'll be left with the
> following:
> - silent is handled 100% by userspace
Care to create a patch for the silent mode now? That should be simple
enough to get into the kernel, and will be a good place to build off of
for the rest of the things people want (verbose mode, etc.)
thanks,
greg k-h
Hi!
> > Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
> > taken from suse kernel. I'll probably try to modify it to work with
> > radeonfb.
> >
> > Any ideas why bootsplash needs to hack into vesafb? It only uses
> > vesafb_ops to test against them before some kind of free...
>
> It doesn't really need vesafb for anything. Back in the days of 2.6.7
> I used to release a version of bootsplash that had the dep. on vesafb
> removed. It worked fine with at least some other fb drivers.
>
> You might also want to save yourself some work and try out an
> alternative solution called fbsplash [1], which I designed after I got
> tired of fixing bootsplash and which I actively maintain. Fbsplash
> provides virtually the same functionality, and it has as much code as
> possible moved into userspace (no more JPEG decoders in the kernel).
mls suggested that there were some problems with matroxfb in the
past. Have you seen something like that?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Mon, Feb 28, 2005 at 06:40:15PM +0100, Pavel Machek wrote:
Hi,
> > It doesn't really need vesafb for anything. Back in the days of 2.6.7
> > I used to release a version of bootsplash that had the dep. on vesafb
> > removed. It worked fine with at least some other fb drivers.
> >
> > You might also want to save yourself some work and try out an
> > alternative solution called fbsplash [1], which I designed after I got
> > tired of fixing bootsplash and which I actively maintain. Fbsplash
> > provides virtually the same functionality, and it has as much code as
> > possible moved into userspace (no more JPEG decoders in the kernel).
> mls suggested that there were some problems with matroxfb in the
> past. Have you seen something like that?
Possibly, but I can't recall what exactly was it about. All bugs in
fbsplash, that I have known of, have been fixed. If there are still some
problems with any fb drivers, please let me know.
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl
On Sun, Feb 27, 2005 at 01:03:33PM -0800, Greg KH wrote:
> Care to create a patch for the silent mode now? That should be simple
> enough to get into the kernel, and will be a good place to build off of
> for the rest of the things people want (verbose mode, etc.)
Sure, I'll post a patch as soon as I get the userspace part ready, so
that there is a way to actually test it.
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl
On Sun, Feb 27, 2005 at 08:41:23PM +0100, Pavel Machek wrote:
Hi,
> [aj added to the list].
>
> Andreas, who is the person to talk about this? I like redhat's
> solution the best. Pass "quiet", perhaps replace penguin with some big
> picture including penguin and chameleon or something, and do the
> interesting work in userspace...
>
> That's the best solution, technically... Perhaps it is even acceptable
> politically?
And that's exactly how it will be done in fbsplash, as soon as I move
the rest of the 'silent'-handling code to the userspace. Fbsplash will
call a userspace helper as soon as fbcon is initialized. The helper can
be used put the console into KD_GRAPHICS mode and paint a full-screen
picture to cover any text messages. Progress bars and other fancy stuff
will be handled after init, by 100% userspace code (it's done that way
even with the current version of fbsplash).
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl
On Tue, Mar 01, 2005 at 02:03:25PM +0100, Michal Januszewski wrote:
> Possibly, but I can't recall what exactly was it about. All bugs in
> fbsplash, that I have known of, have been fixed. If there are still some
> problems with any fb drivers, please let me know.
Well, you'll run into trouble with all drivers that use a non-standard
fb_imageblit, i.e.:
amifb
cirrusfb
cyber2000fb
hgafb
neofb
tdfxfb
tgafb
vga16fb
atyfb
radeon_accel
i810
intelfb
matroxfb_accel
riva
savage
Hmm, maybe I should change the vesafb test in the bootsplash code
to test if fb_imageblit == cfb_imageblit. This would make Pavel
very happy, I guess ;-)
Cheers,
Michael.
--
Michael Schroeder [email protected]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
Hi!
> Hmm, maybe I should change the vesafb test in the bootsplash code
> to test if fb_imageblit == cfb_imageblit. This would make Pavel
> very happy, I guess ;-)
Yes, I like that one. Also it is likely going to be cleaner than
vesafb_ops hack.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Sun, Feb 27, 2005 at 01:03:33PM -0800, Greg KH wrote:
> Care to create a patch for the silent mode now? That should be simple
> enough to get into the kernel, and will be a good place to build off of
> for the rest of the things people want (verbose mode, etc.)
I've just sent the whole thing split up into seven parts. After working
on both fbsplash and splashutils for the last few days, I came to the
conclusion that the initial silent mode patch wouldn't make much sense
(it would create a short fbsplash.c file with a single call to
call_usermodehelper()) and the whole splash interface thing would
completely pointless.
I tried to move as much as possible into userspace. If anyone can find
away to move more code to the userspace, please let me know -- I'd be
glad to make fbsplash even lighter :)
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [email protected] freenode: #gentoo-dev, #gentoo-pl