Re: New proposed DRM interface design

[Jon Smirl]

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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/