The current DRM code doesn't suffer from resource conflicts anymore. DRM now supports two modes: primary and stealth. In primary mode DRM behaves like a Linux device driver should, it attaches to it's PCI IDs, claims it's resources, registers with sysfs, generates hotplug events, etc.
On the other hand, if vesafb or fbdev are loaded they will be attached to all of the resources. DRM is blocked now, it can't load and attach to things like a normal driver. In this case the DRM code reverts to stealth mode. Since vesa/fbdev is already attached to the DRM PCI IDs DRM can't directly attach. Instead the module init code searches the pci bus for DRM hardware. If DRM finds it's hardware DRM will install itself and function without informing the kernel that it is there. Before every one blows up and says how stupid this is, stealth mode came first, it's what DRM originally did. It's the primary mode code that is new. Over time the plan is to give DRM the ability to do take_over_console() and handle printk's. DRM will also gain mode setting capabilities. Once these capabilities are added the need for a standalone fbdev will be eliminated. You will still have all of the fbdev features, they will just be coming out of the integrated code base, not separate drivers. This is not an attempt to build a new fbdev, the existing fbdev code is simply being reused and modified to work in conjunction with DRM. Stealth and primary mode are transition tools. Once DRM subsumes fbdev capabilities stealth mode will not be needed anymore and can be removed. This is a different strategy than building a base driver that claims the resources and then loads vesafb, fbdev and DRM on top of the base. The stealth mode scheme is a smoother transition to coordinating the video drivers since it doesn't require a simultaneous change to all of the video drivers. Stealth/primary mode in DRM is already implemented and tested. Parts of it are already in the kernel and the rest is in the pipeline. On Fri, 10 Sep 2004 23:04:56 +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > On Gwe, 2004-09-10 at 14:31, Felix Kühling wrote: > > The first region (frame buffer and apperture) is claimed (partially) by > > vesafb, the second one (MMIO registers) is not claimed at all. I don't > > see an obvious way to fix this. > > Its already fixed in the stuff I'm working on. Given the list of all > video devices its simply a matter of taking the mmio address and seeing > who owns it. That gives you the PCI device so you now know what the VESA > console is Linux pci_device terms. At that point VESA is attachable to > the PCI device and so it can veto DRI attaches. > > I've not addressed what occurs if you get an answer in the ISA window > because for VESA2 allocations I don't think it can occur. If it does > then Jon's code dealing with finding the live VGA route will handle it > for most boxes. (Anyone using VESA video on an IBM summit can fix it > themselves). > > Alan > -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- 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
