Thread (35 messages) 35 messages, 8 authors, 2004-02-26

Re: fbdv/fbcon pending problems

From: Sven Luther <hidden>
Date: 2004-02-25 14:02:27
Also in: lkml

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.
I wonder about X though. It uses mmio for accels (in the non fbdev case
though) and needs to map the memory area for fallback case, like the non
supported bressenham lines on permedia 2/3 for example. Altough it is
possible that the fact that X does its own mapping, and anyway, has very
little interaction with fbcon and fbdev anyway.

Friendly,

Sven Luther



-------------------------------------------------------
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help