# Using a video as a splash screen



## Deleted member 49176 (Apr 6, 2016)

Let's say I wanted to program and add a video or a high definition animation of some sort as a splash screen, how would I go about doing that in FreeBSD? (I am a beginner of course)


----------



## tobik@ (Apr 8, 2016)

This isn't supported in any way AFAICT.

Once upon a time FreeBSD had support for boot splash screens, but the new console vt(4) doesn't support this. See https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-splash.html and splash(4).


----------



## SirDice (Apr 8, 2016)

tobik said:


> Once upon a time FreeBSD had support for boot splash screens, but the new console vt(4) doesn't support this.


The 'old' sc(4) console still does. For vt(4) it's on the 'feature' list.

https://wiki.freebsd.org/Newcons


----------



## kpa (Apr 8, 2016)

Ideally the console framebuffer device would support the accelerated features of the videocard just like the devices under X do and that would give an easy way to play videos trough it but that's still very far off in FreeBSD.


----------



## Rudoland (Apr 11, 2016)

It is must looking good. You need GIF support in a kernel (very bad idea).


----------



## kpa (Apr 11, 2016)

Rudoland said:


> It is must looking good. You need GIF support in a kernel (very bad idea).



See my reply above, there are proper ways to implement such things as graphics and video playback on a console that do not require polluting the kernel with unnecessary components.


----------



## Rudoland (Apr 16, 2016)

It is very interesting how you are planning make splash before loading userspace utilites and not loading kernel modules (polluting the kernel). UEFI? Modifying boot Stage1,2?


----------



## Pegasus711 (Apr 18, 2016)

Fancy splash screens do make a good project but IMHO it is not a very good idea to do splash (ans similar histrionics) in the bootloader or even in the kernel. That is best done at the user space with it's plethora of supporting libraries and the like.

Nonetheless, YMMV and all the best


----------



## Maelstorm (May 4, 2016)

You could write a kernel module to support animated GIFs and the like and preload it with the kernel and unload it later, but with all the different hardware that is out there, you would need to run it on a generic video mode.  Not all platforms have the same video modes, or even pixel formats!  The problem with doing video is that you would have to code for all the different hardware accelerated chipsets out there (There's still quite a few different ones), and then use a video codec to decode the video and update the screen via the device driver.  Now that is pretty involved because since there is really nothing available at that stage of the booting process, you will have to write everything from the ground up and have it operate correctly in kernel mode without causing a system crash or panic.

I used to have a splash screen, but I removed it because I figured it was better to watch the kernel startup for any errors or problems.  A splash screen hides that.


----------



## Rudoland (May 15, 2016)

How much different platforms working good under FreeBSD? i386, x64  thats all. We are need ARM suupport, but ... So, in intel arch's SVGA 640x480x8bpp support always work good. We have not problems in our poor hardware, but software GIF decode and animate is a problem for a boot stages without UEFI or  additional kernel level modules. However, topic starter says about high definition screens. IMHO, put a heavy graphics capabilities into the kernel level is a big error (this is a windows'95 way with "bugs", "gluck's" and BSOD).


----------



## Maelstorm (May 17, 2016)

I agree.  Historically, the biggest problems with Windows wasn't security (surprise!), it was with buggy device drivers.  In Windows, drivers run at kernel level.  So a buggy device driver will blue screen the computer.  A Windows system with all Microsoft generic drivers is virtually crash-proof...at least in my experience.


----------



## kpa (May 17, 2016)

Maelstorm said:


> I agree.  Historically, the biggest problems with Windows wasn't security (surprise!), it was with buggy device drivers.  In Windows, drivers run at kernel level.  So a buggy device driver will blue screen the computer.  A Windows system with all Microsoft generic drivers is virtually crash-proof...at least in my experience.



So do the device drivers in Linux and FreeBSD. Neither of them implements any micro-kernel features that would separate the drivers from the kernel core to user-space processes.


----------



## Chris_H (May 17, 2016)

OK. I can't stand it. I'll bite. I _pretty_ sure you could do it. Granted, without additional support, HI-DEF is out. But as to an animated startup; this is old stuff, and will work on even the _oldest_ of graphics cards -- their all _bitmaped_ screens.
_So_, if you're a good pixel pusher, and bit shifter, you could probably get Imagemagick's convert() to convert a video into an animated bitmap. H{...}ll, Micro$oft has been doing it for _years_! 

Just a thought. 

--Chris


----------



## Maelstorm (May 25, 2016)

The microkernel design is a good idea, if it was implemented properly.  I am not sure about other platforms, but on IA32 and AMD64, there are four rings of protection.  Ring 3 being user mode, ring 0 being kernel mode.  Now if it was me, I would have all device drivers placed in ring 1.  That way, if a buggy one is loaded, it won't bring down the whole system.


----------

