Re: OpenGL-based framebuffer concepts

["Jon Smirl" <jonsmirl@gmail.com>]

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.

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


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

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