Messages in this thread | | | Date | Fri, 26 May 2006 17:53:22 +0000 | From | Pavel Machek <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |