Re: [Linux-fbdev-devel] fbdv/fbcon pending problems

[Otto Solares <solca@guug.org>]

On Wed, Feb 25, 2004 at 12:41:25PM +0100, Geert Uytterhoeven wrote:
> On Tue, 24 Feb 2004, Otto Solares wrote:
> > On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:
> > > > On the other side i see a lot of effort in the fbdev acceleration,
> > > > it is nice but that effort should be better spent on fixing the layer,
> > > > imo, the only user for acceleration is fbcon, any userland app that
> > > > use fbdev disables that acceleration so it can map the vmem and ioregs,
> > > > and do it's own voodoo if it wants acceleration.  That acceleration
> > > > is not "exported" to user space.  I am working in a open source project
> > > > that uses mesa-solo with fbdev and many limitations from the layer
> > > > itself have been seen.
> > >
> > > That is true so far for fillrect and copyarea functions. Imageblit will be
> > > used for read and writes on /dev/fbX. Also it is used for software
> > > cursors.
> >
> > But if acceleration is not disabled you can't map the vmem and io regions.
> 
> I don't expect an app that mmap()s mmio to read/write from /dev/fb* at the same
> time. So I see no problem disabling accelerated read/write while mmio is
> mapped.

Exactly, that's the whole point, if you want userland accel you must disable
kernel land accel.  That's was my question against acceleration work inside
the kernel.  Nobody use it in userland and is the stability devil in fbdev.
If you want acceleration in userland there is mesa-solo or directfb or console-sdl.

In short acceleration belongs to specialized libs not the kernel.

Why accel it is needed for font drawing?, i am pretty sure my 8bit video old
sparc doesn't have any accel and is pretty capable for drawing fonts.

-otto