My question is about the linux kernel. When framebuffer device initializes (I guess it is vesafb), the screen is filled with black color. How can I change that color? What file should I edit? I guess it is something in drivers/video/.
I only know about changing console background (drivers/tty/vt/vt.c), but this is not what I need. VGA Console is turned off.
In case my description is not clear I have a video that shows my system bootup in a virtual machine. After the kernel is loaded QEMU window changes it's size to 640x480 and becomes completely black (0:03-0:04). This is what I want to modify. After it my init is started. It outputs text to framebuffer and then dies, causing kernel panic and reboot in 1sec. Then everything starts over.
The console implementation in vt.c started out as a VGA console once upon a time, but it is now used for all consoles.
(The 'attribute byte' is mapped to whatever the underlying hardware driver actually supports.)
Change the initialization of vc_def_color in vc_init().
Since version 3.12, this can also be changed with the kernel parameter vt.color.
Related
I am trying to draw things on the screen without an X11 server. (I want my program to be in initrd, so I don't want to bloat it with X11.)
It's easy when I have /dev/fb0, but when I use Xen, I don't have it (also I am not sure how that works - the passing of vesafb to the kernel by grub and such).
I've tried SDL but it won't work without /dev/fb0 or X11. How does X11 work without /dev/fb0? It seems like no matter what I do X11 will always work... yet all libraries (like directfb, SDL, etc.) will fail.
the /dev/fb0 handeling with kernel. you must enable:
CONFIG_FRAMEBUFFER_CONSOLE if you want to enable 'df' for console
CONFIG_DRM and VGA card driver in this.
FB and your VGA card driver in this.
I am working on an appliance that runs on Linux (Ubuntu 10.04 for now) and x86-64 Intel based PC. I need to completely customize the boot screens - no BIOS messages, and either (a) no screen output until X is launched or (b) custom screen output via VESA/VBE.
(b) looks hard to achieve because none of the framebuffer drivers (vesafb, uvesafb) seem to support addressing pixels on more than 2 monitors being driven by the same graphics card
So, I'm looking at (a) : no output on screen until X is launched. This should mean no Dell BIOS output, no Ubuntu splash screen, no console output.
Any ideas will be much appreciated.
I don't know much about the framebuffer stuff, but I can tell you for sure that you'll have no control over the BIOS output from Linux.
In the boot process, BIOS comes first, then the boot loader, then Linux. So when Linux appears, the BIOS stuff is done for long.
Consider a live GNU/Linux distro with the following constraints: all the software should be contained in an initrd image (which results in its huge size) and the kernel contains as few statically-compiled modules as possible.
Consider the bootup process of the described distro: the bootloader (e.g. grub or isolinux) loads the kernel, which then loads and extracts the initrd into the memory. During the extraction (which takes 20-30 seconds on old computers) nothing happens on the screen.
I was wondering, is there a ready-made solution of showing a splash screen during the initrd extraction process? If not, can you please comment on the following ideas:
Statically compile an e.g. 600x480x8bit image into the kernel and somehow flush it into the framebuffer while initrd is being extracted.
Do the same, but force a particular video driver to be loaded (e.g. VESA) and hack into its code, rather that kernel's framebuffer.
Thank you.
Perhaps you can make it simpler: Create 2 initrd files. The first one can be small. Then it can call Plymouth to show a splash screen while the real initrd is extracted.
You are wrong if you think, that the kernel loads the initrd image. It is done by the boot loader. If you want to show a splash screen you have to tell your boot loader to display an image. How to do this depends on your boot loader.
You might try creating a plain .ppm file and use LZMA compression for the Kernel Compression Mode. This might be done by using the boot logo option, but not sure if it will work for you.
First you need to enable support in your kernel for Bootup logo and Standard 224-color Linux Logo:
Device Drivers —> Graphics Support –>
Support for frame buffer devices
VESA VGA graphics support
Video mode selection support
Framebuffer Console support
Select compiled-in fonts
VGA 8×16 font
Bootup logo
Standard 224-color Linux log
Second,if supposed that you have a .png image named screen.png, you need to generate the appropiate .ppm file:
pngtopnm screen.png| ppmquant -fs 223 | pnmtoplainpnm > /usr/src/linux/drivers/video/logo/logo_linux_clut224.ppm
Then just compile, install, update your bootloader and check if it works for you.
In embedded programming, it's often needed to replace the default Linux boot output by some custom 'loading' animation or splash screen from power-on to up-and-running.
What is the way to achieve this?
Is there a way to use the same 'process' throughout the whole boot sequence for that?
How can this be solved? I'm guessing we need a home-brew kernel for that?
Thanks!
The solution usually goes along the lines of:
Optionally, put a static image on the screen from the boot loader code (e.g. uboot, syslinux, redboot).
Using the Linux kernel command line "quiet" directive to suppress normal kernel load output (and speed up boot time while you're at it).
As one of the very first programs started from init, draw your splash animation throughout the boot init sequence until it is finished.
For example, Android phones usually put some static image in the boot loader and then run the surfaceflinger program from the startup init scripts to draw the animated Android logo until the boot is finished.
I'm working on embedded device with screen rotated 90 degrees clockwise: screen controller reports 800x600 screen, while device's screen is 600x800 portrait.
What do you think, whose responsibility it is to compensate for this: should kernel rotate framebuffer to provide 800x600 screen as expected by upper-level software or applications (X server, bootsplash) should adapt and draw to rotated screen?
Every part of stack is free software, so there are no non-technical problems for modification, the question is more about logical soundness.
It makes most sense for the screen driver to do it - the kernel after all is supposed to provide an abstraction of the device for the userspace applications to work with. If the screen is a 600x800 portrait oriented device, then that's what applications should see from the kernel.
yes,I agree, The display driver should update the display accordingly and keep the control
Not sure exactly how standard your embedded device is, if it is running a regular linux kernel, you might check in the kernel configurator (make xconfig, when compiling a new kernel) , one of the options for kernel 2.6.37.6 in the device, video card section, is to enable rotation of the kernel messages display so it scrolls 90 degrees left or right while booting up.
I think it also makes your consoles be rotated correctly after login too.
This was not available in kernels even 6-8 months ago, at least not available in kernel that slackware64 13.37 came with about that time.
Note that the bios messages are still rotated on a PC motherboard,
but that is hard-coded in the bios, which may not apply to the embedded system you are working with.
If this kernel feature is not useful to you for whatever reason, how they did it in the linux kernel might be good example of where and how to go about it. Once you get the exact name of the option from "make xconfig", it should be pretty easy to search where ever they log the kernel traffic for that name and dig up some info about it.
Hmmm. I just recompiled my kernel today, and I may have been wrong about how new this option is. Looks like it was available with some kernel versions before the included-with-Slackware64 versions that I referenced. Sorry!