Subject: Re: New proposed DRM interface design
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Keith Whitwell <keith@tungstengraphics.com>, Dave Jones <davej@redhat.com>,
       Christoph Hellwig <hch@infradead.org>, Dave Airlie <airlied@linux.ie>,
       Jon Smirl <jonsmirl@yahoo.com>,
       DRI Devel <dri-devel@lists.sourceforge.net>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       mharris@redhat.com
In-Reply-To: <9e47339104090514122ca3240a@mail.gmail.com>
References: <20040904102914.B13149@infradead.org>
	 <4139B03A.6040706@tungstengraphics.com> <20040904122057.GC26419@redhat.com>
	 <4139C8A3.6010603@tungstengraphics.com>
	 <9e47339104090408362a356799@mail.gmail.com>
	 <4139FEB4.3080303@tungstengraphics.com>
	 <9e473391040904110354ba2593@mail.gmail.com>
	 <1094386050.1081.33.camel@localhost.localdomain>
	 <9e47339104090508052850b649@mail.gmail.com>
	 <1094398257.1251.25.camel@localhost.localdomain>
	 <9e47339104090514122ca3240a@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1094417612.1936.5.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Sun, 05 Sep 2004 21:53:41 +0100
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1666
Lines: 35

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

-
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/