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

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.

quoted

By 'fixing the layer' i mean some simple things that could make fbdev
a real graphics solution for linux in the long term:

- fbdev_core (will handle the fbdev/sysfs registration, shared by all
              drivers, most important is the modes handling interface).

Pretty much done.

quoted

- fbdev_xxx  (driver for specific hw, it will only export the interesting
              bits like vmem, ioregs, will handle mmap stuff and ioctl's,
              video modes, no accel of any kind).

Have it.

quoted

- fbdev_xxx_accel (acceleration hooks if any for xxx driver, optional module)

We need it for the above reasons.

quoted

- fbdev_con  (handle console -- already modular in 2.6, will use accel hooks
              if not NULL, optional).

We always need the accel hooks. Some how we have to draw the fonts.

Ok, i get your point about accel.  My point is that accel for userland is
already there in Mesa-solo with the DRI accelerated drivers or with directfb,
we just need the basic linux graphics infrastructure with the following
functionality so specialized libraries (like the above) integrate nicely with
the fbdev.

In summary:

1. Card identification.
	A simple bus_id will do this hopefully on any platform.
2. Port identification.
	I don't think exists a form to determine this with the current
	functionality, MacOSx excells in this area.
3. Modes list supported by the card per graphics port.
	As BenH noted, filtered by constraints like mem bandwitdh, etc.
	hopefully using EDID or any other monitor info present.
4. Memory mappings.
	We can currently map the vmem and io regions in userspace.  It
	current exists problems with highmem but in short it simply works
	for dumb chips or programable chips so specialized libs (like
	mesa-solo) can do a decent job.
5. sysfs interface.
	So we can control the behavior with libsysfs to change video modes, get
	card/monitor info, etc.
6. DRM or card's command queue.
	For use in the mentioned DRI drivers or any other project based on that.
7) read/write/other_fs_ops/ioctl.
	So current fbdev software works without problems.
8) Graphics console.

1) is trivial.
2) 3) 5) and 6) is what needs work or is lacking currently.
4) and 7) 8) are already done and was a major step for graphics on linux in
   its time.

I am by no means a graphics expert like you or BenH but i think the mentioned
above should express general userland needs.

quoted

We have now with 2.6 a good input and sound layers.  Just by fixing
the graphics layer many interesting userland projects could be born.

I agree. The graphics layer is the last frontier.

Yes, it will bring Linux on the Desktop an unavoidable reality, being part
this basic functionality of the kernel is what one expects from a modern system
but many could argument that is job for userland libs, probably true, anyway
we need a (preferably graphics) console early in the boot process.

-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