All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Gerards <metgerards@student.han.nl>
To: grub-devel@gnu.org
Subject: Framebuffer
Date: Fri, 15 Oct 2004 13:51:26 +0000	[thread overview]
Message-ID: <878ya8144h.fsf@marco.marco-g.com> (raw)

Hi,

As I quickly mentioned in my email yesterday, I want to have a look at
the vga terminal.  This vga terminal is just one of the many
framebuffers that will be implemented, as far as I am concerned.  On
the PC we will have the VESA terminal someday.  It should be possible
to get a framebuffer on the new world macs too.  On some machines
there is only a framebuffer and no textmode.

To avoid code duplication it might be the best to write one generic
terminal called framebuffer which can be configured to work with many
kinds of framebuffers.  In this email I will write down a suggestion
how it should work.  I have little experience with framebuffers on a
lot of machines so I am not sure if what I am suggestion is sane or
portable.  I hope you will make suggestions to make this design as
good as possible or come forwards with alternative solutions.

The main thing that I want to do is creating a generic terminal called
"framebuffer".  On its own it is useless, but it can communicate with
another kind of modules, video drivers.

The framebuffer should always be initialized with a video driver and
depending on the size of the screen and its depth it reserves memory.
Whenever a character is written to the terminal, the generic
framebuffer driver writes it to the internal buffer.  When it is
required to synchronize the screen that is displayed with the one in
memory, it calls a function in the video driver.

To speed up things the framebuffer sends updates to the video driver
with updates so not the entire buffer has to be copied.  The
video driver is responsible to write the updates to video memory, bank
switching and making sure it is displayed on the screen.  That means
the video driver can do stuff like double buffering, etc.

The main advantage of this approach is that the framebuffer terminal
can do anything including showing the splashimage, etc.  All smart
things happen there, the video drivers just do the stupid work.  That
means that whenever someone wants to implement a framebuffer, he only
has to write a video driver and not a complete terminal driver.

Does this make sense or does this just suck?  I hope many people will
reply on this so I can start hacking ASAP.

Thanks,
Marco




             reply	other threads:[~2004-10-15 14:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-15 13:51 Marco Gerards [this message]
2004-10-15 14:12 ` Framebuffer Johan Grip
2004-10-15 14:34   ` Framebuffer Marco Gerards
2004-10-15 14:40     ` Framebuffer Johan Grip
2004-10-15 15:15       ` Framebuffer Marco Gerards
2004-10-15 15:28         ` Framebuffer Johan Rydberg
2004-10-15 15:32         ` Framebuffer Yoshinori K. Okuji
2004-10-15 22:49           ` Framebuffer Marco Gerards
2004-10-16 11:40             ` Framebuffer Yoshinori K. Okuji
2004-10-16 12:27               ` Framebuffer Marco Gerards
2004-10-17 20:28 ` Framebuffer Yoshinori K. Okuji
2004-10-17 20:34   ` Framebuffer Marco Gerards
2004-10-17 20:48     ` Framebuffer Yoshinori K. Okuji
2004-10-17 20:59       ` Framebuffer Marco Gerards

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=878ya8144h.fsf@marco.marco-g.com \
    --to=metgerards@student.han.nl \
    --cc=grub-devel@gnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.