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.
Truecolor, directcolor and pseudocolor modes are supported. Fbsplash has
no dependency on a specific framebuffer driver. It has been tested with
at least vesafb, rivafb and radeonfb.
Technical details about the userspace<->kernelspace interface can be
found in patch 07/07, which contains the documentation.
The userspace utilities that make use of fbsplash can be found on:
http://dev.gentoo.org/~spock/projects/splashutils/
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
> 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.
On Tue, 8 Mar 2005 19:46:23 +0000 (GMT), James Simmons
<jsimmons@http://www.infradead.org> wrote:
> 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.
--
Jon Smirl
[email protected]
Eye candy.
> On Tue, 8 Mar 2005 19:46:23 +0000 (GMT), James Simmons
> <jsimmons@http://www.infradead.org> wrote:
> > 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.
>
> --
> Jon Smirl
> [email protected]
>
On Tuesday 08 March 2005 09:57, Michal Januszewski wrote:
> 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.
Tony
On Wed, 9 Mar 2005 13:01:15 +0800, Antonino A. Daplas
<[email protected]> wrote:
> On Tuesday 08 March 2005 09:57, Michal Januszewski wrote:
> > 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.
--
Jon Smirl
[email protected]
On Wed, 9 Mar 2005, Jon Smirl wrote:
> 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, ...
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
Hi!
> > 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, Gentoo and SUSE each use some variant of this
eye candy; each one with different bugs. It would be nice to at least
do the splash right (so that it does not require vesafb and therefore
allows working with suspend-to-RAM).
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 Mer, 2005-03-09 at 09:34, Geert Uytterhoeven wrote:
> On Wed, 9 Mar 2005, Jon Smirl wrote:
> > 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.
Alan
> On Mer, 2005-03-09 at 09:34, Geert Uytterhoeven wrote:
> > On Wed, 9 Mar 2005, Jon Smirl wrote:
> > > 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.
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.
On Wed, 9 Mar 2005, Alan Cox wrote:
> On Mer, 2005-03-09 at 09:34, Geert Uytterhoeven wrote:
> > On Wed, 9 Mar 2005, Jon Smirl wrote:
> > > 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.
Thanks for correcting me!
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
On Mer, 2005-03-09 at 20:45, James Simmons wrote:
> 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.
On Wed, Mar 09, 2005 at 12:38:42PM +0100, Pavel Machek wrote:
> Hi!
>
> > > 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,
While there might be a kernel-patch-bootsplash package in Debian none of
the shipped binary kernels use this.
And there's a kernel-patch- package for just about every piece of random
junk.
On Wed, 9 Mar 2005, Alan Cox wrote:
> On Mer, 2005-03-09 at 20:45, James Simmons wrote:
> > 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.
Gr{oetje,eeting}s,
Geert
P.S. Many years ago, when I discussed integrating the so-called `abstract
console driver', which allowed to have vgacon and fbcon in the kernel, I
also pondered to make the console a simple tty in response to a `KISS'
request. Now it's time to make that happen ;-)
--
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
Hi!
> > > 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.
>
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.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
> > > 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.
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.
On Fri, 11 Mar 2005 18:03:20 +0000 (GMT), James Simmons
<jsimmons@http://www.infradead.org> wrote:
> > > > 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.
>
> 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.
--
Jon Smirl
[email protected]
Hi!
> > > > 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.
>
> 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.
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, 13 Mar 2005, Pavel Machek wrote:
> > > > > 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.
> >
> > 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.
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
On Fri, Mar 11, 2005 at 06:03:20PM +0000, James Simmons wrote:
>
> > > > 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.
>
> 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.
Putting it in userland would make it impossible to debug what's wrong
with the system if there's a kernel error, since userland will die long
before it can spit out anything useful.
The primary purpose of these things is to make a distribution look
pretty while booting. Lots of people complain that Linux distros look
"old fashioned" or something because they don't show little dancing
girls during early boot.
I should think the primary features you need here are:
* Can display some pretty looking thing with a logo
* If there's a problem during boot (userspace error, oops, panic, etc.)
then it should become a regular console able to scroll back over the
boot-time spew.
I don't think a user-space version can do that for anything except
userspace errors, so a kernel console is better.
-J
On Sun, 13 Mar 2005 19:53:55 +0100 (CET), Geert Uytterhoeven
<[email protected]> wrote:
> On Sun, 13 Mar 2005, Pavel Machek wrote:
> > > > > > 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.
> > >
> > > 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.
>
> Indeed. I thought the idea was to use the existing fbcon support to draw
> emergency messages to the screen.
That is the idea. I would like to even simplify the fbcon/dev even
more in this model and remove all in-kernel acceleration in fbdev.
The user space console would be fully accelerated using DRM. If we
aren't using fbcon for normal console then it doesn't need to be
accelerated and that source of conflicts can be removed. fbcon would
be used for system recovery, OOPs, boot, kdbg, etc only kernel use, no
normal logins.
>
> 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
>
--
Jon Smirl
[email protected]
> > 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.
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.
On Tue, 15 Mar 2005 18:58:08 +0000 (GMT), James Simmons
<jsimmons@http://www.infradead.org> wrote:
>
> > > 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.
>
> 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.
--
Jon Smirl
[email protected]
> 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 all devices are DMA. Personally since it is generic DMA engine then
why not move it to the device api so everyone could use it. We already
have DMA pools. Actually I have started some work for some generic DMA
handling for the device api core but I have other fish to fry first.
On Tue, 2005-03-15 at 18:58 +0000, James Simmons wrote:
> Not every device has a 3D core!!! DRM is not the answer for the entire graphics
> world. Its only for 3D functionality.
Not quite. It's also to support hardware accelerated MPEG like on the
Unichrome boards.
Lee