Re: Advice sought on approach.
From: Alex Bennee <hidden>
Date: 2003-03-05 14:40:10
On Wed, 2003-03-05 at 13:26, Antonino Daplas wrote:
On Wed, 2003-03-05 at 20:37, Alex Bennee wrote:quoted
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.
quoted
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