fbsplash - The Framebuffer Splash

Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash.

What are you trying to do exactly? I really don't see the point of this patch.

Quoted 2 lines · James Simmons

What are you trying to do exactly? I really don't see the point of this patch.

I think it makes a graphical background on your console that stays in place as the console text scrolls.

Signature · 2 lines

Jon Smirl
[email protected]

Quoted 3 lines

Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash.

What are you trying to do exactly? I really don't see the point of this patch.

Hi!

Quoted 6 lines

Quoted 3 lines

Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash.

What are you trying to do exactly? I really don't see the point of this patch.

At least some Debians,

Quoted 4 lines · Pavel Machek

Quoted 4 lines

Quoted 3 lines

Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash.

Quoted 4 lines

Quoted 2 lines

What are you trying to do exactly? I really don't see the point of this patch.

At least some Debians,

While there might be a kernel-patch-bootsplash package in Debian none of the shipped binary kernels use this.

Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash.

Unlike bootsplash, fbsplash has no in-kernel image decoder. Picture decompression is handled by a userspace helper which provides raw image data to the kernel. There is also no support for things like the silent mode and progress bars, as these are best handled by userspace programs.

Quoted 9 lines · Michal Januszewski

Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash.

Unlike bootsplash, fbsplash has no in-kernel image decoder. Picture decompression is handled by a userspace helper which provides raw image data to the kernel. There is also no support for things like the silent mode and progress bars, as these are best handled by userspace programs.

If splash support is really, really, really wanted in the kernel, it's probably better to just add minimal Overlay support for the framebuffer. If overlay is added, it won't be necessary to modify fbcon and the drivers, just core fb.

We can have 3 levels of support. In it's most basic form, we have the display layer (what get's shown in your monitor) plus 2 buffers in system ram, the primary layer (where the console output is written) and the overlay, the static image in raw framebuffer format. Then we replace the basic framebuffer operations (imageblit, fillrect and copyarea) with ones that will read the contents of both buffers, do basic raster ops (colorkey, alpha blend, etc) before writing to the actual display buffer.

The next level is both buffers are in video ram. This will need basic driver support, at least to subdivide the framebuffer memory to display, primary, and overlay. We can use the drivers accelerated drawing functions to write to the primary layer, then use software to write the processed contents to the display layer.

Finally, we can enable full hardware video overlay.

Another idea would be to build a console is user space. Think of it as a full screen xterm. A user space console has access to full hardware acceleration using the DRM interface.

Quoted 3 lines · Jon Smirl

Another idea would be to build a console is user space. Think of it as a full screen xterm. A user space console has access to full hardware acceleration using the DRM interface.

Yep. And that's what Alan Cox wanted to do. Console in userspace, eye candy (using Porter-Duff blending) as much as you want, full UTF-8 support, ...

Quoted 7 lines · Geert Uytterhoeven

Quoted 3 lines · Jon Smirl

Another idea would be to build a console is user space. Think of it as a full screen xterm. A user space console has access to full hardware acceleration using the DRM interface.

Yep. And that's what Alan Cox wanted to do. Console in userspace, eye candy (using Porter-Duff blending) as much as you want, full UTF-8 support, ...

Jon is the origin of those ideas not me, I'm merely supporting them providing there is still a basic kernel side console.

Quoted 5 lines · Jon Smirl

Quoted 3 lines

Another idea would be to build a console is user space. Think of it as a full screen xterm. A user space console has access to full hardware acceleration using the DRM interface.

Quoted 2 lines

Yep. And that's what Alan Cox wanted to do. Console in userspace, eye candy (using Porter-Duff blending) as much as you want, full UTF-8 support, ...

Jon is the origin of those ideas not me, I'm merely supporting them providing there is still a basic kernel side console.

Thank you. We need some kind of basic console in the kernel. I'm not the biggest fan of eye candy. So moving the console to userspace for eye candy is a dumb idea.

Quoted 3 lines · James Simmons

Thank you. We need some kind of basic console in the kernel. I'm not the biggest fan of eye candy. So moving the console to userspace for eye candy is a dumb idea.

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Quoted 7 lines

Quoted 3 lines

Thank you. We need some kind of basic console in the kernel. I'm not the biggest fan of eye candy. So moving the console to userspace for eye candy is a dumb idea.

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace.

Quoted 8 lines

Quoted 4 lines

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace.

Heh, I'm afraid it does not work like that. Anyone who wants eye-candy simply applies broken patch to their kernel... unless their distribution applied one already.

Situation where we have one working eye-candy patch would certainly be an improvement.

Quoted 12 lines

Quoted 7 lines

Quoted 3 lines

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace.

Heh, I'm afraid it does not work like that. Anyone who wants eye-candy simply applies broken patch to their kernel... unless their distribution applied one already.

Quoted 2 lines

Situation where we have one working eye-candy patch would certainly be an improvement.

Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel.

Quoted 5 lines

Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel.

/dev/fb is not accelerated, if you want full acceleration use /dev/dri. Using /dev/dri you can write a fully composited console that displays dengavi in realtime. This is also a path to getting multiuser working without a lot of kernel patches.

Quoted 6 lines

Quoted 5 lines

Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel.

Quoted 4 lines

/dev/fb is not accelerated, if you want full acceleration use /dev/dri. Using /dev/dri you can write a fully composited console that displays dengavi in realtime. This is also a path to getting multiuser working without a lot of kernel patches.

Not every device has a 3D core!!! DRM is not the answer for the entire graphics world. Its only for 3D functionality. If you want eye candy without 3D on small devices use fbdev.

DRM doesn't know a thing about 3D. All it does is DMA, memory management and queue things up for the GPU to work on. You don't even have to have a GPU processor you could use the CPU to execute the commands.

It's the code up in mesa that knows about 3D and builds the commands to be sent to DRM.

Not every device has a 3D core!!! DRM is not the answer for the entire graphics world. Its only for 3D functionality.

Quoted 12 lines

Quoted 7 lines

Quoted 3 lines

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace.

Heh, I'm afraid it does not work like that. Anyone who wants eye-candy simply applies broken patch to their kernel... unless their distribution applied one already.

Quoted 2 lines

Situation where we have one working eye-candy patch would certainly be an improvement.

Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel.

Quoted 15 lines

Quoted 14 lines

Quoted 7 lines

Quoted 3 lines

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace.

Heh, I'm afraid it does not work like that. Anyone who wants eye-candy simply applies broken patch to their kernel... unless their distribution applied one already.

Situation where we have one working eye-candy patch would certainly be an improvement.

Quoted 4 lines

Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel.

Except that I'll not get usefull reports from Oopsen and panic's, right? Ideally I'd also like high-priority kernel messages to be displayed during boot.

Quoted 20 lines · Pavel Machek

Quoted 19 lines

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace.

Quoted 6 lines

Heh, I'm afraid it does not work like that. Anyone who wants eye-candy simply applies broken patch to their kernel... unless their distribution applied one already.

Situation where we have one working eye-candy patch would certainly be an improvement.

Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel.

Quoted 3 lines

Except that I'll not get usefull reports from Oopsen and panic's, right? Ideally I'd also like high-priority kernel messages to be displayed during boot.

Indeed. I thought the idea was to use the existing fbcon support to draw emergency messages to the screen.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Linux-fbdev-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Quoted 13 lines

Quoted 8 lines

Quoted 4 lines

Thats why moving the eye candy console into user space is such a good idea. You don't have to run it 8) It also means that the console development is accessible to all the crazy rasterman types.

Yep. The basic console we already have. Everyone who wants eye candy can switch from basic console to user space console in early userspace.

Heh, I'm afraid it does not work like that. Anyone who wants eye-candy simply applies broken patch to their kernel... unless their distribution applied one already.

Quoted 2 lines

Situation where we have one working eye-candy patch would certainly be an improvement.

Why do we need patches in the kernel. Just set you config to CONFIG_DUMMY_CONSOLE, CONFIG_FB, CONFIG_INPUT and don't set fbcon or vgacon. Then have a userspace app using /dev/fb and /dev/input create a userland console. There is no need to do special hacks in the kernel.