Re: OpenGL-based framebuffer concepts

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

On Friday 26 May 2006 17:53, Pavel Machek wrote:
> Hi!
>
> > > Step 1: add a layer between fbdev and DRM so that they can see each
> > > other.
> > >
> > > Do *NOT* merge fbdev and DRM this is the "wrong answer". They may end
> > > up merged but firstly let them at least become away of each others
> > > existence, perhaps a lowerlayer driver that handles PCI functionality.
> > > All other Step 1s are belong to us.
> >
> > Okay. This won't be simple, won't be pretty, but I should be able to
> > handle it. The problem then becomes: What exactly should this system do?
> > A layer that sits on top of the PCI/AGP stuff and mediates it for
> > DRM/fbdev? Isn't easy, isn't simple but I think it is possible.
> >
> > Any other option though, would seem to require rebuilding a good deal of
> > both DRM and fbdev, if not replacing the driver model, because of
> > difficulties you have previously pointed out.
> >
> > If DRM makes use of the lower-level driver, and so does fbdev, then it's
> > likely possible that the system can provide the information needed to
> > allow the kernel to composite error messages onto the framebuffer.
> >
> > And, really, if there is a common PCI layer beneath the two graphics
> > systems, they could potentially have some interaction... though to retain
> > the capacity to compile DRM or fbdev out of the kernel there is no way
> > that one could depend on the other. Having them intercommunicate, it
> > seems, would require a third mechanism. Any pointers?
>
> Well, if drm and fbdev become interdependend while cleaning up... I do
> not think it is too big problem.
> 							Pavel

It's not that, it's that if DRM uses the middle layer to ask the framebuffer 
for information about the memory layout then it becomes dependant on systems 
present in the framebuffer driver. The same holds true for the framebuffer 
using DRM to provide acceleration features.

DRH