linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Alex Bennee <kernel-hacker@bennee.com>
Cc: Linux Fbdev development list <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Advice sought on approach.
Date: 05 Mar 2003 21:26:46 +0800	[thread overview]
Message-ID: <1046870757.1229.94.camel@localhost.localdomain> (raw)
In-Reply-To: <1046867855.2505.200.camel@cambridge.braddahead>

On Wed, 2003-03-05 at 20:37, Alex Bennee wrote:
> Hi,
> 
> I'm writting a framebuffer driver for an embedded system that has a
> overlayed video display (TV picture + Overlayed text). To do this I have
> to keep track of both the main pixel memory and a mask that the hardware
> uses to display things. This is also compilcated by the fact I can't
> access this memory directly, it is done through a small addr/data port
> on the hardware so obviosuly I want to minimise the amount of data I
> push through this (by doing it only when required).
> 
> Having read the fb-dev docs on www.linux-fbdev.org I'm a little confused
> as to what actually puts data into the framebuffer. Most of the
> framebuffer drivers just seem to deal with resolution and colourmap
> settings. Is this a case of having to re-implement the fbcon drivers as
> well to get what I want?
> 

The pixels placed to the framebuffer are all done in the fbcon-cfb*.c
modules (if you use the generic functions).  This is for standard
character drawing.  The logo is drawn indepently (fbcon_show_logo in
fbcon.c).  User applications write directly to the framebuffer via the
mmap() function.

> Are there any examples of drivers that have a similar architecture that
> would be worth looking at? I've had a look at the vfb.c code but again
> that seems too simplistic compared to what I'll need.

Search the archives for SED1335.  The author implemented a shadowed
virtual framebuffer using system memory.  The contents of the virtual
framebuffer are written to the data port periodically via a timer
function.

> 
> Final question, the docs refer to 2.2. Is this because under 2.4
> framebuffer drivers are not fundamentally differnt?

Yes.

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  reply	other threads:[~2003-03-05 13:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-05 12:37 Advice sought on approach Alex Bennee
2003-03-05 13:26 ` Antonino Daplas [this message]
2003-03-05 14:40   ` Alex Bennee
2003-03-05 14:44     ` Geert Uytterhoeven
2003-03-05 15:36     ` Antonino Daplas

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=1046870757.1229.94.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=kernel-hacker@bennee.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /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).