Alan, I would like to disagree with you.
On Fri, 10 Sep 2004, Alan Cox wrote:
On Gwe, 2004-09-10 at 23:19, Dave Airlie wrote:If the kernel developers can address this point I would be most interested, in fact I don't want to hear any more about sharing lowlevel VGA device drivers until someone addresses why it is acceptable to have two separate driver driving the same hardware for video and not for anything else.. (remembering graphics cards are not-multifunction cards - like Christoph used as an example before - 2d/3d are not separate functions...)...
We've addressed this before. Zillions of drivers provide multiple functions to multiple higher level subsystems. They don't all have to be compiled together to make it work.
2D and 3D _are_ to most intents and purposes different functions. They are as different as IDE CD and IDE disk if not more so.
Functions - yes, but they become such only at a higher level. 3d for example does not really exist in kernel in any form.
I would like to see unified fb (or the hardware-specific part of fb) and drm for one simple reason that I think you mentioned:
One driver per device. I.e. one driver per *physical* device.
Lastly, one point that you appear to have missed: DRM does DMA transfers
(among everything else). FB sets video modes - i.e. messes with PLL.
The problem is that there are configurations where messing with PLL while a DMA trasfer is active will lock up PCI (or AGP) bus hard.
For example, a video decoder can be clocked off pixel clock for video pass through mode. If we trasfer video data to main RAM at the same time and
FB gets a command instructing it to change resolution there would be a hard lockup.
best
Vladimir Dergachev
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
