On Sun, Feb 08, 2004 at 08:27:17PM -0800, Jon Smirl wrote:
> I have a new version of DRM at bk://mesa3d.bkbits.net/drm
> In it's current form it's 2.6 kernel only. Some support is generic but I've
> mainly be working on an R200. It is still under development with lots of work to
> do.
Ugh. I find the idea of OpenGL as the one and only API really disturbing.
I don't want to layer another high level API over OpenGL.
I'll just write some of my ideas here. Naturally I don't have any code to
actually implement any of this so feel free to ignore it...
Here's a quick and dirty chart of how I think things should be organised.
----------------------------------
user space
-----------------------
| fbdev + fbcon | drm |
----------------------------------
memory manager/arbitration/DMA/irq
----------------------------------
I like the idea of reducing fbdev to something that just writes the
registers and they could be calculated in user space by a trusted
application (fbset, xserver...). And fbdev would just notify fbcon
whenever this happens and fbcon would feed the correct values back to
fbdev on a VT switch. Fbdev would use the low-level module for irq support
but besides that I don't think there's much more that it would need. Maybe
overlays and such could also be handled through fbdev.
I want to bypass the drm to do accel from user space. Doing an ioctl() for
each blit feels very expensive. Rather than do an ioctl() for each blit
the drm could check the commands in the DMA buffer for bad stuff. But that
doesn't feel very efficient either. If you don't care about the security I
think you should be allowed to bypass it to gain some speed. And of course
there may be cards without DMA so you may need the ability to do MMIO
stuff directly.
The memory manager component could probably take care of agpgart usage as
well as video memory. Drm could use this to check blits, clears and
whatnot. And yes I want to allow access to the framebuffer memory from
user space.
And finally I find the current situation with multi-head cards quite
bad. I'd like the ablitity for a user space app to open the whole card
as one entity. That includes all CRTCs, outputs and the whole memory
(minus whatever is in use by other stuff like DMA stuff and video
capture). If the app doesn't want to handle such details it would just get
whatever is used by the current VT.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
