lkml.org 
[lkml]   [2004]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.357 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site