Menu
▾
▴
linux-fbdev-devel
|
From: Alex B. <ker...@be...> - 2003-03-05 12:37:48
|
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 |
|
From: Antonino D. <ad...@po...> - 2003-03-05 13:25:28
|
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 |
|
From: Alex B. <ker...@be...> - 2003-03-05 14:40:12
|
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. |
|
From: Geert U. <ge...@li...> - 2003-03-05 14:45:52
|
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 -- ge...@li... 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 |
|
From: Antonino D. <ad...@po...> - 2003-03-05 15:35:37
|
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 |
Thanks for helping keep SourceForge clean.
X