Re: OpenGL-based framebuffer concepts

["D. Hazelton" <dhazelton@enter.net>]

On Sunday 28 May 2006 02:34, Jon Smirl wrote:
> On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> > Yes, I noticed this while studying the DRM code. Part of me doing this,
> > actually, will also be updating the DRM in kernel to the latest release.
> > (Doing such provides at least one new DRM driver that already has it's X
> > counterpart in the 6.8.2 tree)
>
> DaveA will take care of merging drivers from CVS into the kernel tree.
> Drivers that are in CVS and not in the kernel are probably there
> because their DMA engines are not secure. With Direct Rendering normal
> users can submit DMA commands to the GPUs. The kernel drivers check
> these commands and make sure that the user isn't using the DMA
> controller to play with memory that they don't own. If the DRM driver
> is missing these checks it can't go into the kernel since it isn't
> secure. I'd ignore DRM CVS and just play with the code in the kernel
> tree.

Okay. Wasn't aware of any major differences in the code - in fact, I'm using 
the CVS on my machine right now. (Not that it works - I can't get *any* 
acceleration, even using binary-only drivers from the card manufacturer)

> > Fully merging fbdev with DRM would really create some problems for the
> > embedded people. If the design of using the fbdev driver as a base layer
> > and the DRM drivers as an acceleration layer works then that's all that's
> > truly needed. Merging the DRM and fbdev code bases would create a
> > situation where the embedded people would have to configure *out* the DRM
> > code that has been merged into the fbdev drivers. Not only would such a
> > thing create potential bugs in the system, it is a step that could create
> > problems with people maintaining the .config's for those systems.
>
> It may cause problems for some embedded people but I wouldn't worry
> about them right now. If they don't like something I'm sure we'll hear
> from them. Most people don't go to the expense of putting a DRM
> capable chip into a system and then not use all of its capabilities.
> Remember, only 8 out of the 60 fbdev drivers have DRM modules.
>
> Worst thing that can happen is that they lose 50K of memory. Don't
> spend a lot of effort worrying about this especially if no one is
> complaining. Issues like this can be addressed later.

Yes, however, I don't think a lot of embedded people are putting DRM capable 
chips in their machines. And I will worry about that at all points, to great 
length - I will actually fight to keep a complete merger from happening. For 
exactly the reasons I stated above.

> > > BTW, I have already submitted a patch that does this and it was
> > > rejected. I might be able to find it somewhere, but the dependency
> > > code is not very hard to write.
> >
> > If you can find it Jon, I'd appreciate it. If not, then I'll have to dive
> > into the code head first and hope I don't drown in it.
>
> I'll poke around and see if I can find it, but it probably wouldn't
> merge anymore.  It took me less than a day to write it so it shouldn't
> be too hard to recreate. Just add a do nothing function to each of the
> 8 fbdev drivers and then make each of the 8 DRM drivers call it. Then
> adjust the include and make files until everything compiles. You're
> not trying to change anything yet, you're just trying to bind them to
> each other.

Thanks.

DRH