--- Ville Syrjälä <[EMAIL PROTECTED]> wrote: > 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.
This is exactly what we are trying to stop. Right now user space apps are writing whatever they want to the video card. Now think about what has to happen on a VT switch. Don't forget that the app in the next VT can be doing the exactly the same thing and writing whatever it wants to the video hardware. Every register of the card has to be saved and restored. We have to have special code that looks for an active CP or DMA and wait for it finish and then save it's state then start DMA and the CP with the new VT's data. We have to unload up to 1GB of VRAM and load it again with fresh content. AGP memory has to be saved/restored. MTRR's have to be set. We have to sort out pending interrupts. It is also a security nightmare. User space access to the video hardware can be used to root the machine. The VT system was not designed as a multitasking system for video device drivers. If you want to write a system that saves all of this state, I'd be happy to look at it. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ------------------------------------------------------- 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
