Re: Mapping the framebuffer into kernel space

[Jon Smirl <jonsmirl@gmail.com>]

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