Messages in this thread | | | Date | Thu, 25 May 2006 19:19:42 -0400 | From | Jeff Garzik <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
Jon Smirl wrote: > On 5/25/06, Jeff Garzik <jeff@garzik.org> wrote: >> Jon Smirl wrote: >> In Linux, the lowlevel driver registers irq handlers, so your simple >> problem has the simple and obvious answer. Further, reviewing my >> statement above, if fbdev/DRM are aware of each other, and if they both >> are layered on top of the lowlevel driver, then it should also be >> obvious that they are cooperatively sharing resources, not competing >> against one another. >> >> >> > I would instead start by making fbdev the low level driver. DRM could >> > then bind to it and redundant code in DRM could be removed. 90% of the >> > code in fbdev is always needed. Hopefully X could be convinced to use >> >> Take your pick. An fbdev driver is nothing but a PCI driver that >> registers itself with the fbdev subsystem. Ditto a DRM driver, though >> the DRM and agpgart layering is royally screwed up ATM. Regardless, he >> who codes, wins. > > There is significant architectural difference between the two schemes. > Is the base driver an absolute minimal driver that only serves as a > switch to route into the other drivers, or does the base driver > contain all the common code? I'm in the common code camp, DaveA is in > the minimal switch camp.
You are missing that both are the same camp. It's just different paths to get to the same destination. Common code will inevitably result.
> Take memory management for example. I think the memory manager should > go into the base driver. The other strategy is for each driver to have > their own memory manager and then the base provides a way to select > which one is active. (Note that in all cases the complex part of > memory management is running in user space).
That's an implementation detail that will naturally fall out of fbdev/DRM cooperation. Don't worry, it will solve itself.
>> > the services offered by the fbdev/DRM pair. New memory management code >> >> No "hopefully." X must be forced to use this driver, otherwise the >> system is unworkable. > > I have had no success in making this happen.
If the code is merged into the Linux kernel, X will follow. Its axiomatic.
Jeff
- 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/
| |