Advice sought on approach.

Advice sought on approach.

[Alex Bennee]

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?

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.

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


-- 
Alex, homepage: http://www.bennee.com/~alex/

Any sufficiently advanced bug is indistinguishable from a feature.
		-- Rich Kulawiec



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

Re: Advice sought on approach.

[Antonino Daplas]

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

Re: Advice sought on approach.

[Alex Bennee]

On Wed, 2003-03-05 at 13:26, Antonino Daplas wrote:
> On Wed, 2003-03-05 at 20:37, Alex Bennee wrote:
> > 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.

I think I understand now. When the fb_set_disp function is called I fill
in the display struction with the console display operations. I've got
two choices now:

1. Create a new fbcon_cfb16 file which notes the changed areas before
calling the generic function.

2. Patch the current fbcon_cfb16 (with a CONFIG option) to add the
change tracking facility in a more generic way.

I guess the question is is it worth doing 2 as a potential upstream
patch? Or is this sort of thing so specialised I should just keep it all
packed in my own fb driver?

I guess I can't easily implement user access via mmap without uploading
the entire screen, which I'm not intending to do anyway because all I
really need is the console support - at least for now.

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

I couldn't find anything in the mail archives but after some careful
googling I found this site (posted for reference):
ftp://ssv-embedded.de/ssv/products/trm916/sample/x86/linux/fbdev which
seems to be the one your refering to.

Thanks for the pointer, seeing the code made things a lot clearer :-)

-- 
Alex, homepage: http://www.bennee.com/~alex/

Bennett's Laws of Horticulture:
	(1) Houses are for people to live in.
	(2) Gardens are for plants to live in.
	(3) There is no such thing as a houseplant.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Advice sought on approach.

[Geert Uytterhoeven]

On 5 Mar 2003, Alex Bennee wrote:
> On Wed, 2003-03-05 at 13:26, Antonino Daplas wrote:
> > On Wed, 2003-03-05 at 20:37, Alex Bennee wrote:
> > > 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.
> 
> I think I understand now. When the fb_set_disp function is called I fill
> in the display struction with the console display operations. I've got
> two choices now:
> 
> 1. Create a new fbcon_cfb16 file which notes the changed areas before
> calling the generic function.
> 
> 2. Patch the current fbcon_cfb16 (with a CONFIG option) to add the
> change tracking facility in a more generic way.
> 
> I guess the question is is it worth doing 2 as a potential upstream
> patch? Or is this sort of thing so specialised I should just keep it all
> packed in my own fb driver?
> 
> I guess I can't easily implement user access via mmap without uploading
> the entire screen, which I'm not intending to do anyway because all I
> really need is the console support - at least for now.

If all you need is console support, please take a look at
drivers/video/newport_con.c, for the SGI Indy.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Advice sought on approach.

[Antonino Daplas]

On Wed, 2003-03-05 at 22:40, Alex Bennee wrote:
> 
> I think I understand now. When the fb_set_disp function is called I fill
> in the display struction with the console display operations. I've got
> two choices now:
> 
> 1. Create a new fbcon_cfb16 file which notes the changed areas before
> calling the generic function.
> 
> 2. Patch the current fbcon_cfb16 (with a CONFIG option) to add the
> change tracking facility in a more generic way.
> 
> I guess the question is is it worth doing 2 as a potential upstream
> patch? Or is this sort of thing so specialised I should just keep it all
> packed in my own fb driver?
> 

Either do #1 (create your own set -- check the popular drivers which has
acceleration, they have their own set), or you can generically implement
#2, I think.  It may even become useful for devices without mappable
graphics memory.

Or as Geert suggested, just write a console driver if you don't need
GUI.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com