Martin Husemann hat also geschrieben:

> This sounds all backward. What DRI part are we talking about? 
> Is this the chip specific driver that provides abstract DRI services and
> attaches to the same hardware as, for example, vga @ pci?
> 
> There are a lot of different ways to organize this. Maybe we even need to
> allow multiple of them:
> 
>   - vga @ pci and radeondri @ agp both share the hardware via some (tm)
>     kind of cooperation.
>   - radeondri @ agp owns the hardware, and allows vga @ radeondri (by
>     forwarding some of it's bus_space variables, restricted to the common
>     vga set)
>   - radeondri @ agp completely replaces vga @ pci and directly allows
>     wsdisplay @ radeondri (probably using code shared with vga @ pci)

You need also to take into account the radeon framebuffer we try 
currently to debug. radeonfb @ agp masks vga @ pci because only one 
driver can get attached to a piece of hardware, if I read my NetBSD 
correctly. Method 2 is more or less what I was suggesting. But since 
there seems to be at least three different drivers competing for the 
same space and hardware, I would suggest a forth proposal: developing a 
radeon @ pci generic driver that would do nothing but map the chip and 
offer access to vga @ radeon, radeonfb @ radeon and radeondri @ radeon. 
If this makes somehow sense.

Macht einfach, aber nicht einfacher! ;)
Vincent