On Wed, Feb 25, 2004 at 12:41:25PM +0100, Geert Uytterhoeven wrote:

On Tue, 24 Feb 2004, Otto Solares wrote:

quoted

On Wed, Feb 25, 2004 at 01:21:39AM +0000, James Simmons wrote:

quoted

quoted

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



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click