Messages in this thread | | | Date | Sun, 5 Sep 2004 18:11:25 -0400 | From | Jon Smirl <> | Subject | Re: New proposed DRM interface design |
| |
What is the advantage to continuing a development model where two groups of programmers work independently, with little coordination on two separate code bases trying to simultaneously control the same piece of hardware? This is a continuous source of problems. Why can't we fix the development model to stop this?
On Sun, 05 Sep 2004 21:53:41 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Sul, 2004-09-05 at 22:12, Jon Smirl wrote: > > Sure you can use this to get around both fbdev and DRM trying to claim > > the resource. But it doesn't help at all to fix the problem that fbdev > > and DRM are programming the radeon chip in conflicting ways. > > Once you have the common structure the rest of the problems go away > rather nicely over time. > > > What is so awful about merging the code? I'm the one doing the all of > > the work. I intend to use 95% of the code extracted from fbdev without > > change. I'm not getting rid of fbdev capability in the merged code, > > I'm just coordinating use of the hardware. > > It doesn't solve the problem. That is the fundamental part of it. I can > put the code in the same place or in different places, the problem you > have to fix is co-ordination, and when you fix that not suprisingly you > still don't care where the code lives. > > Create a top level video device object to hold dri and fb info pointers. > End of problem #1. Make that top level video object the one which is > handling the pci device irrespective of DRI/fb loading first. You've now > solved the load order problem. Make DRI tell fb about display layout in > X and provide sync functions. You've now solved the Oops problem. > > After that you can begin to worry about dual head and memory management > which is a *lot* harder than you seem to realise and much of which > cannot be done user space side for performance reasons. > > Alan > >
-- Jon Smirl jonsmirl@gmail.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |