Re: OpenGL-based framebuffer concepts

[Pavel Machek]

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
-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/