* Mapping the framebuffer into kernel space
@ 2005-04-29 3:55 Jon Smirl
2005-05-02 17:43 ` James Simmons
2005-05-07 3:08 ` Antonino A. Daplas
0 siblings, 2 replies; 20+ messages in thread
From: Jon Smirl @ 2005-04-29 3:55 UTC (permalink / raw)
To: fbdev, Antonino A. Daplas
I looked at a few fbdev drivers and they are mapping the framebuffer
into kernel space.
Example from radeonfb:
rinfo->mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM, rinfo->video_ram);
do {
rinfo->fb_base = ioremap (rinfo->fb_base_phys,
rinfo->mapped_vram);
Isn't the only consumer of this kernel mapping fbconsole? If so
shouldn't fbconsole be doing the mapping instead of doing it in the
drivers? Doing it in fbconsole would let us map exactly the amount of
VRAM needed for the console. Right now the driver has to guess the
maximum consumption. This would minimize the amount of kernel address
space consumed by fbdev. It could also remove a bunch of redundant
code.
Then in my case where I'm running radeonfb but not fbconsole there
would be no kernel address space consumed at all.
Minimizing kernel address space consumption is important for x86
systems with more than 1GB of memory. Address space going to fbdev
pushes system pages from low into high memory and slows them down.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id\x105hix
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-04-29 3:55 Mapping the framebuffer into kernel space Jon Smirl
@ 2005-05-02 17:43 ` James Simmons
[not found] ` <9e473391050504104529f1f080@mail.gmail.com>
2005-05-07 3:08 ` Antonino A. Daplas
1 sibling, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-02 17:43 UTC (permalink / raw)
To: fbdev; +Cc: Antonino A. Daplas
> Isn't the only consumer of this kernel mapping fbconsole?
No that is not the case. fb_read and fb_write use the kernel mapping.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e473391050504104529f1f080@mail.gmail.com>
@ 2005-05-04 18:08 ` James Simmons
[not found] ` <9e47339105050416415f4dfb1f@mail.gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-04 18:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-fbdev-devel, James Simmons, Antonino A. Daplas
> I don't see a good solution here for implementing fb_read/write for
> the framebuffer. I would still vote for removing all kernel
> framebuffer mapping from the fbdev driver. Then fbconsole would kernel
> map just the piece it needs to implement the console.
I like to see the mappings go away as well. The solution is for fb_read
and fb_write to use fb_imageblit. We don't need to touch the framebuffer
memory in that case. The logic is a little tricky. You could have 1 to 3
images blitted to the display.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e47339105050416415f4dfb1f@mail.gmail.com>
@ 2005-05-05 16:43 ` James Simmons
[not found] ` <9e47339105050511522f6eff30@mail.gmail.com>
2005-05-06 9:30 ` Geert Uytterhoeven
0 siblings, 2 replies; 20+ messages in thread
From: James Simmons @ 2005-05-05 16:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-fbdev-devel, James Simmons, Antonino A. Daplas
> What if we just got rid of fb_read/write and converted fbconsole to
> use fb_imageblt?
fbconsole does use only fb_imageblit. The only place where screen_base
is used is fb_write and fb_read in fbmem.c. If that could be converted to use
the accelerated image blitting functions then we could replace it. To do
that requires one thing and that is to add image blitting from screen
memory to system memory. Currently no driver including the software
blitting supports that. Plus we have no standard api to handle that.
So first we have to come up with a standard way to handling image
blitting from card memory to system memory without breaking badly the
current api. Second we have to add bi directional blitting to every
driver. Then once we are done we can convert the fb_read and fb_write
functions to using the fb_imageblit functon. Have have plans to do this
but have not yet done it.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e47339105050511522f6eff30@mail.gmail.com>
@ 2005-05-05 18:59 ` James Simmons
[not found] ` <9e473391050505122635f1cf@mail.gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-05 18:59 UTC (permalink / raw)
To: Jon Smirl; +Cc: linux-fbdev-devel, James Simmons, Antonino A. Daplas
> > fbconsole does use only fb_imageblit. The only place where screen_base
> > is used is fb_write and fb_read in fbmem.c. If that could be converted to use
> > the accelerated image blitting functions then we could replace it. To do
>
> So if fbconsole doesn't use fb_read/write then who does?
/dev/fb
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e473391050505122635f1cf@mail.gmail.com>
@ 2005-05-05 20:43 ` James Simmons
[not found] ` <9e4733910505051402789440db@mail.gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-05 20:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: James Simmons, linux-fbdev-devel, Antonino A. Daplas
> > > So if fbconsole doesn't use fb_read/write then who does?
> >
> > /dev/fb
>
> and what app uses /dev/fb with read/write instead of mmaping the framebuffer?
I can't say off the top of my head. We should assume there are apps that
do use those functions.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e4733910505051402789440db@mail.gmail.com>
@ 2005-05-05 23:47 ` James Simmons
[not found] ` <9e473391050505170161b0a38d@mail.gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-05 23:47 UTC (permalink / raw)
To: Jon Smirl; +Cc: James Simmons, linux-fbdev-devel, Antonino A. Daplas
> > I can't say off the top of my head. We should assume there are apps that
> > do use those functions.
>
> fb_read/write has been broken on radeon for a couple of years now and
> nobody has noticed.
I have a hard time believing that. Do a cat /dev/urandom > /dev/fb0
and see what the results are. I can give it a try.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-05 16:43 ` James Simmons
[not found] ` <9e47339105050511522f6eff30@mail.gmail.com>
@ 2005-05-06 9:30 ` Geert Uytterhoeven
2005-05-06 19:07 ` James Simmons
1 sibling, 1 reply; 20+ messages in thread
From: Geert Uytterhoeven @ 2005-05-06 9:30 UTC (permalink / raw)
To: Linux Frame Buffer Device Development
Cc: Jon Smirl, James Simmons, Antonino A. Daplas
On Thu, 5 May 2005, James Simmons wrote:
> > What if we just got rid of fb_read/write and converted fbconsole to
> > use fb_imageblt?
>
> fbconsole does use only fb_imageblit. The only place where screen_base
> is used is fb_write and fb_read in fbmem.c. If that could be converted to use
> the accelerated image blitting functions then we could replace it. To do
> that requires one thing and that is to add image blitting from screen
> memory to system memory. Currently no driver including the software
> blitting supports that. Plus we have no standard api to handle that.
> So first we have to come up with a standard way to handling image
> blitting from card memory to system memory without breaking badly the
> current api. Second we have to add bi directional blitting to every
> driver. Then once we are done we can convert the fb_read and fb_write
> functions to using the fb_imageblit functon. Have have plans to do this
> but have not yet done it.
What if the graphics memory format is not chunked pixels? In that case
fb_{read,write}() will behave differently than mmap().
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: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-06 9:30 ` Geert Uytterhoeven
@ 2005-05-06 19:07 ` James Simmons
0 siblings, 0 replies; 20+ messages in thread
From: James Simmons @ 2005-05-06 19:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Frame Buffer Device Development, Jon Smirl, James Simmons,
Antonino A. Daplas
> > So first we have to come up with a standard way to handling image
> > blitting from card memory to system memory without breaking badly the
> > current api. Second we have to add bi directional blitting to every
> > driver. Then once we are done we can convert the fb_read and fb_write
> > functions to using the fb_imageblit functon. Have have plans to do this
> > but have not yet done it.
>
> What if the graphics memory format is not chunked pixels? In that case
> fb_{read,write}() will behave differently than mmap().
Is that a bad thing? It would be nice to have a application behave sanely
in all cases. Even for pack pixel formated cards they might misbehave.
For the Epson135X family we have the issue of only being able to write 16
bits at a time to the framebuffer memory. Unless you write the code
knowing before hand this issue you will drop every other pixel for both
mmap and write cases. Now if we rework fb_write then that chip would
behave the same as other chips for the read/write function. The other
bonus with a nice read/write function is you can NFS mount the fbdev
device and read/write to it. To my knowledge you can't use mmap remotely.
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e47339105050517083fadaee0@mail.gmail.com>
@ 2005-05-06 19:08 ` James Simmons
[not found] ` <9e47339105050615097bdfcdcb@mail.gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-06 19:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: James Simmons, linux-fbdev-devel, Antonino A. Daplas
> This does imply that we could switch read/write to kernel map VRAM a
> page or two at a time on demand. But this is significant work and I
> don't think there are any apps using read/write. If we find one it
> would just be easier to convert it to mmap than to support read/write
> in the kernel.
Yuck. Why not just us the image blitter for reading and writing the
framebuffer?
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-04-29 3:55 Mapping the framebuffer into kernel space Jon Smirl
2005-05-02 17:43 ` James Simmons
@ 2005-05-07 3:08 ` Antonino A. Daplas
[not found] ` <9e47339105050620312618d2b7@mail.gmail.com>
1 sibling, 1 reply; 20+ messages in thread
From: Antonino A. Daplas @ 2005-05-07 3:08 UTC (permalink / raw)
To: linux-fbdev-devel, Jon Smirl
On Friday 29 April 2005 11:55, Jon Smirl wrote:
> I looked at a few fbdev drivers and they are mapping the framebuffer
> into kernel space.
>
> Example from radeonfb:
> rinfo->mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM,
> rinfo->video_ram); do {
> rinfo->fb_base = ioremap (rinfo->fb_base_phys,
> rinfo->mapped_vram);
>
> Isn't the only consumer of this kernel mapping fbconsole? If so
> shouldn't fbconsole be doing the mapping instead of doing it in the
> drivers? Doing it in fbconsole would let us map exactly the amount of
> VRAM needed for the console. Right now the driver has to guess the
> maximum consumption. This would minimize the amount of kernel address
> space consumed by fbdev. It could also remove a bunch of redundant
> code.
It can be done but not without difficulty. A few drivers use sections of
the framebuffer space for the cursor, DMA buffer and whatever. So
when fbcon starts mapping the framebuffer space, it must make sure
that it does not overlap with the driver's, or the space left to the driver
is of the correct size and alignment.
Tony
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e47339105050615097bdfcdcb@mail.gmail.com>
@ 2005-05-11 22:46 ` James Simmons
2005-05-12 9:14 ` Geert Uytterhoeven
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-11 22:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: James Simmons, linux-fbdev-devel, Antonino A. Daplas
> > Yuck. Why not just us the image blitter for reading and writing the
> > framebuffer?
>
> Could you generically rewrite fb_read/write to just use the image blitter?
Yes.
> Is this a solution to eliminating the kernel mmap?
Yes.
We would need to make imageblit bi-directional tho for all the drivers.
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
[not found] ` <9e47339105050620312618d2b7@mail.gmail.com>
@ 2005-05-12 0:38 ` James Simmons
0 siblings, 0 replies; 20+ messages in thread
From: James Simmons @ 2005-05-12 0:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: adaplas, Linux Fbdev development list
> > It can be done but not without difficulty. A few drivers use sections of
> > the framebuffer space for the cursor, DMA buffer and whatever. So
> > when fbcon starts mapping the framebuffer space, it must make sure
> > that it does not overlap with the driver's, or the space left to the driver
> > is of the correct size and alignment.
>
> We have to start transitioning to a new model. 512MB cards are
> shipping today. There is only 1GB of x86 kernel address space and the
> kernel has to fit into it too. Blindly mapping the entire VRAM into
> kernel space has to be replaced with a scheme that only maps what is
> required.
This can be done. I was moving that way using fb_pixmap. See my
resource.diff patch I posted some time ago. Using request_region we should
be able to lock down a area so no one else can use it.
> Space for the cursor, DMA buffer, etc doesn't have to stay mapped. The
> driver can map it in, write the cursor and then map it out. DMA
> buffers don't need to be mapped in.
The cursor is really small memory. Mapping and unmapping it would be
expensive with fbconsole because it flashs the cursor. As for DMA that
can be mapped and unmapped.
> Another issue is multihead cards. For two heads it makes sense to put
> the two scanout buffers at either end of VRAM. But these buffers can
> change size. A better model might be:
>
> cursor
> head 1 scanout
> free VRAM
> head 2 scanout
> cursor
>
> The location of these items would be pointed to by a field in fb_info.
Each struct fb_info represent each displayable surface with a cursor[s].
It has the data the fbcon needs to function. The function check_var
needs to valided if changing one head can safely affect the other.
The function set_par would handle doing the moving around of resources.
> What's the least painful way to start a transition?
Design a clean buffer implementation that dri and fb would use.
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-11 22:46 ` James Simmons
@ 2005-05-12 9:14 ` Geert Uytterhoeven
2005-05-12 15:50 ` James Simmons
0 siblings, 1 reply; 20+ messages in thread
From: Geert Uytterhoeven @ 2005-05-12 9:14 UTC (permalink / raw)
To: Linux Frame Buffer Device Development
Cc: Jon Smirl, James Simmons, Antonino A. Daplas
On Wed, 11 May 2005, James Simmons wrote:
> > > Yuck. Why not just us the image blitter for reading and writing the
> > > framebuffer?
> >
> > Could you generically rewrite fb_read/write to just use the image blitter?
>
> Yes.
No.
The imageblit routines convert between chunked pixels and the actual frame
buffer representation.
fb_{read,write}() access the raw frame buffer.
Probably the best solution is to set up a small ioremap()'ed window that can be
moved in fb_{read,write}() (assumed moving such a window is much cheaper than
ioremap() + iounmap()).
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 Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-12 9:14 ` Geert Uytterhoeven
@ 2005-05-12 15:50 ` James Simmons
2005-05-12 17:38 ` Jon Smirl
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-12 15:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Frame Buffer Device Development, Jon Smirl, James Simmons,
Antonino A. Daplas
> > > Could you generically rewrite fb_read/write to just use the image blitter?
> >
> > Yes.
>
> No.
>
> The imageblit routines convert between chunked pixels and the actual frame
> buffer representation.
> fb_{read,write}() access the raw frame buffer.
That means that we will never uses the hardware acceleration ever in this
case :-( It will always be slow!!!!
> Probably the best solution is to set up a small ioremap()'ed window that can be
> moved in fb_{read,write}() (assumed moving such a window is much cheaper than
> ioremap() + iounmap()).
Does such functionality exist? Second can you do the same thing with
request_region? We need to so fbcon and /dev/fb don't step on each other
toes.
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-12 15:50 ` James Simmons
@ 2005-05-12 17:38 ` Jon Smirl
2005-05-12 19:59 ` Geert Uytterhoeven
0 siblings, 1 reply; 20+ messages in thread
From: Jon Smirl @ 2005-05-12 17:38 UTC (permalink / raw)
To: James Simmons
Cc: Geert Uytterhoeven, Linux Frame Buffer Device Development,
Antonino A. Daplas
On 5/12/05, James Simmons <jsimmons@www.infradead.org> wrote:
>
> > > > Could you generically rewrite fb_read/write to just use the image blitter?
> > >
> > > Yes.
> >
> > No.
> >
> > The imageblit routines convert between chunked pixels and the actual frame
> > buffer representation.
> > fb_{read,write}() access the raw frame buffer.
>
> That means that we will never uses the hardware acceleration ever in this
> case :-( It will always be slow!!!!
>
> > Probably the best solution is to set up a small ioremap()'ed window that can be
> > moved in fb_{read,write}() (assumed moving such a window is much cheaper than
> > ioremap() + iounmap()).
>
> Does such functionality exist? Second can you do the same thing with
> request_region? We need to so fbcon and /dev/fb don't step on each other
> toes.
Before we get too far into this, has anyone determined if any user
space app exists that does read/write from fbdev? I can't see a real
need to keep this feature if no one is using it. If no one is using
it, it would be much simpler just to remove the functions.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id\x16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-12 17:38 ` Jon Smirl
@ 2005-05-12 19:59 ` Geert Uytterhoeven
2005-05-12 20:12 ` Jon Smirl
0 siblings, 1 reply; 20+ messages in thread
From: Geert Uytterhoeven @ 2005-05-12 19:59 UTC (permalink / raw)
To: Jon Smirl
Cc: James Simmons, Linux Frame Buffer Device Development,
Antonino A. Daplas
On Thu, 12 May 2005, Jon Smirl wrote:
> On 5/12/05, James Simmons <jsimmons@www.infradead.org> wrote:
> >
> > > > > Could you generically rewrite fb_read/write to just use the image blitter?
> > > > Yes.
> > >
> > > No.
> > >
> > > The imageblit routines convert between chunked pixels and the actual frame
> > > buffer representation.
> > > fb_{read,write}() access the raw frame buffer.
> >
> > That means that we will never uses the hardware acceleration ever in this
> > case :-( It will always be slow!!!!
> >
> > > Probably the best solution is to set up a small ioremap()'ed window that can be
> > > moved in fb_{read,write}() (assumed moving such a window is much cheaper than
> > > ioremap() + iounmap()).
> >
> > Does such functionality exist? Second can you do the same thing with
> > request_region? We need to so fbcon and /dev/fb don't step on each other
> > toes.
>
> Before we get too far into this, has anyone determined if any user
> space app exists that does read/write from fbdev? I can't see a real
> need to keep this feature if no one is using it. If no one is using
> it, it would be much simpler just to remove the functions.
I think the only programs really using this are some screenshot programs, like
cfb8toppm (which I wrote as a frame buffer sample program many years ago),
fbshot, and fbgrap (in Debian).
Of course these can be converted to use mmap().
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 Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-12 19:59 ` Geert Uytterhoeven
@ 2005-05-12 20:12 ` Jon Smirl
2005-05-13 20:35 ` James Simmons
0 siblings, 1 reply; 20+ messages in thread
From: Jon Smirl @ 2005-05-12 20:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Simmons, Linux Frame Buffer Device Development,
Antonino A. Daplas
On 5/12/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Before we get too far into this, has anyone determined if any user
> > space app exists that does read/write from fbdev? I can't see a real
> > need to keep this feature if no one is using it. If no one is using
> > it, it would be much simpler just to remove the functions.
>
> I think the only programs really using this are some screenshot programs, like
> cfb8toppm (which I wrote as a frame buffer sample program many years ago),
> fbshot, and fbgrap (in Debian).
>
> Of course these can be converted to use mmap().
Seems to me that it would be easier to drop the feature and update the apps.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id\x16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-12 20:12 ` Jon Smirl
@ 2005-05-13 20:35 ` James Simmons
2005-05-13 20:56 ` Jon Smirl
0 siblings, 1 reply; 20+ messages in thread
From: James Simmons @ 2005-05-13 20:35 UTC (permalink / raw)
To: Jon Smirl
Cc: Geert Uytterhoeven, James Simmons,
Linux Frame Buffer Device Development, Antonino A. Daplas
> > > Before we get too far into this, has anyone determined if any user
> > > space app exists that does read/write from fbdev? I can't see a real
> > > need to keep this feature if no one is using it. If no one is using
> > > it, it would be much simpler just to remove the functions.
> >
> > I think the only programs really using this are some screenshot programs, like
> > cfb8toppm (which I wrote as a frame buffer sample program many years ago),
> > fbshot, and fbgrap (in Debian).
> >
> > Of course these can be converted to use mmap().
>
> Seems to me that it would be easier to drop the feature and update the apps.
Since you are in a hurry why not just create a write and a read function
for radeon that just returns EINVAL. There are hooks in fb_info for this.
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Mapping the framebuffer into kernel space
2005-05-13 20:35 ` James Simmons
@ 2005-05-13 20:56 ` Jon Smirl
0 siblings, 0 replies; 20+ messages in thread
From: Jon Smirl @ 2005-05-13 20:56 UTC (permalink / raw)
To: James Simmons
Cc: Geert Uytterhoeven, James Simmons,
Linux Frame Buffer Device Development, Antonino A. Daplas
On 5/13/05, James Simmons <jsimmons@www.infradead.org> wrote:
>
> > > > Before we get too far into this, has anyone determined if any user
> > > > space app exists that does read/write from fbdev? I can't see a real
> > > > need to keep this feature if no one is using it. If no one is using
> > > > it, it would be much simpler just to remove the functions.
> > >
> > > I think the only programs really using this are some screenshot programs, like
> > > cfb8toppm (which I wrote as a frame buffer sample program many years ago),
> > > fbshot, and fbgrap (in Debian).
> > >
> > > Of course these can be converted to use mmap().
> >
> > Seems to me that it would be easier to drop the feature and update the apps.
>
> Since you are in a hurry why not just create a write and a read function
> for radeon that just returns EINVAL. There are hooks in fb_info for this.
There is no hurry, radeonfb is already not mapping the entire
framebuffer. But we should make a decision on this and implement it
consistently going forward.
Summary of my points:
1) kernel x86 address space is 1GB
2) ATI is shipping 512MB cards, with 1GB cards planned
3) mapping the entire framebuffer in to kernel space is probably
impossible on x86
4) fbconsole can do it's own map for the limited piece it needs
5) that leaves fb_read/fb_write. I propose eliminating them and
removing the ability to read/write the framebuffer from the fbdev
device. Then fix up the few apps using read/write to use mmap instead.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id\x16281&op=click
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2005-05-13 20:56 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-29 3:55 Mapping the framebuffer into kernel space Jon Smirl
2005-05-02 17:43 ` James Simmons
[not found] ` <9e473391050504104529f1f080@mail.gmail.com>
2005-05-04 18:08 ` James Simmons
[not found] ` <9e47339105050416415f4dfb1f@mail.gmail.com>
2005-05-05 16:43 ` James Simmons
[not found] ` <9e47339105050511522f6eff30@mail.gmail.com>
2005-05-05 18:59 ` James Simmons
[not found] ` <9e473391050505122635f1cf@mail.gmail.com>
2005-05-05 20:43 ` James Simmons
[not found] ` <9e4733910505051402789440db@mail.gmail.com>
2005-05-05 23:47 ` James Simmons
[not found] ` <9e473391050505170161b0a38d@mail.gmail.com>
[not found] ` <9e47339105050517083fadaee0@mail.gmail.com>
2005-05-06 19:08 ` James Simmons
[not found] ` <9e47339105050615097bdfcdcb@mail.gmail.com>
2005-05-11 22:46 ` James Simmons
2005-05-12 9:14 ` Geert Uytterhoeven
2005-05-12 15:50 ` James Simmons
2005-05-12 17:38 ` Jon Smirl
2005-05-12 19:59 ` Geert Uytterhoeven
2005-05-12 20:12 ` Jon Smirl
2005-05-13 20:35 ` James Simmons
2005-05-13 20:56 ` Jon Smirl
2005-05-06 9:30 ` Geert Uytterhoeven
2005-05-06 19:07 ` James Simmons
2005-05-07 3:08 ` Antonino A. Daplas
[not found] ` <9e47339105050620312618d2b7@mail.gmail.com>
2005-05-12 0:38 ` James Simmons
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).