Re: OpenGL-based framebuffer concepts

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

On 5/27/06, D. Hazelton <dhazelton@enter.net> wrote:
> > > 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.

For a specific DRM chip there are currently four modules:
fbdev-core
fbdev-chip depends on fbdev-core
drm-core
drm-chip depends on drm-core
RIght now drm and fbdev can be loaded independently.

I would always keep fbdev-core and drm-core as separate modules.  But
drm-core may become dependent on fbdev-core.

So after merging, drivers without DRM would still load exactly what
they load today. They wouldn't need to load the dependent drm-core
module. These non-DRM modules are essentially unchanged.
fbdev-core
fbdev-chip depends on fbdev-core

Merged DRM drivers can end up in one of two configurations
fbdev-core
fbdev-chip depends on fbdev-core
drm-core depends on fbdev-core
drm-chip depends on fbdev-chip, drm-core, fbdev-core

fbdev-core
drm-core depends on fbdev-core
merged-chip depends on drm-core, fbdev-core

I'm saying don't worry too much if it is more efficient to create
merged-chip for somthing like the Radeon instead of keeping fbdev-chip
and drm-chip. It is more important to get a stable functioning driver
working. If someone really complains the driver can be broken back up
at a later date (they can always use the old fbdev driver in the
meanwhile). If you spend all of your time worrying about 10K of memory
for some embedded system that may or may not use the driver, you won't
be spending enough time on getting the basic driver right.

In the new model you won't be able to load standalone DRM. That's
becuase both of those modules are now dependent on their fbdev counter
parts.
drm-core - standalone disallowed
drm-chip - standalone disallowed

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