linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Michal Januszewski <spock@gentoo.org>,
	linux-kernel@vger.kernel.org,
	"Antonino A. Daplas" <adaplas@hotpop.com>
Subject: Re: [announce 0/7] fbsplash - The Framebuffer Splash
Date: Wed, 9 Mar 2005 01:02:25 -0500	[thread overview]
Message-ID: <9e473391050308220218cc26a3@mail.gmail.com> (raw)
In-Reply-To: <200503091301.15832.adaplas@hotpop.com>

On Wed, 9 Mar 2005 13:01:15 +0800, Antonino A. Daplas
<adaplas@hotpop.com> 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
jonsmirl@gmail.com


-------------------------------------------------------
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

  reply	other threads:[~2005-03-09  6:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-08  1:57 [announce 0/7] fbsplash - The Framebuffer Splash Michal Januszewski
2005-03-08 19:46 ` James Simmons
2005-03-08 20:52   ` Jon Smirl
2005-03-08 22:27     ` James Simmons
2005-03-09 11:38   ` [Linux-fbdev-devel] " Pavel Machek
2005-03-09 22:47     ` Christoph Hellwig
2005-03-09  5:01 ` Antonino A. Daplas
2005-03-09  6:02   ` Jon Smirl [this message]
2005-03-09  9:34     ` Geert Uytterhoeven
2005-03-09 18:16       ` [Linux-fbdev-devel] " Alan Cox
2005-03-09 20:33         ` Geert Uytterhoeven
2005-03-09 20:45         ` James Simmons
2005-03-09 22:40           ` [Linux-fbdev-devel] " Alan Cox
2005-03-10  9:12             ` Geert Uytterhoeven
2005-03-10 14:54               ` Pavel Machek
2005-03-11 18:03                 ` [Linux-fbdev-devel] " James Simmons
2005-03-11 18:13                   ` Jon Smirl
2005-03-15 18:58                     ` James Simmons
2005-03-15 19:03                       ` Jon Smirl
2005-03-15 19:22                         ` James Simmons
2005-03-15 20:39                       ` [Linux-fbdev-devel] " Lee Revell
2005-03-13 18:20                   ` Pavel Machek
2005-03-13 18:53                     ` Geert Uytterhoeven
2005-03-13 19:24                       ` Jon Smirl
2005-03-13 19:34                   ` [Linux-fbdev-devel] " Elladan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e473391050308220218cc26a3@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=adaplas@hotpop.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spock@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).