![]() | |||||||||||
Messages in this thread |
> > 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. The scope of the lower layer system isn't defined, it should be able to do what a driver needs it to do, so this can be in the simple case provide a flag to tell the DRM the fb driver is loaded and vice versa, up to doing suspend/resume handling and PCI handling. I think at the very least it will have to do PCI handling and device model support. > 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. That is the theory, the DRM usually knows where X has the framebuffer. > 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? Yes you could move some common functionality into a lowlevel driver which they could talk to, then compiling out either one wouldn't matter. > > I could even drop the last hack I did in some sort of patch form > > somewhere, I might even have a git tree (not sure...) > > That might be helpful. Okay I've put up two patches at http://www.skynet.ie/~airlied/patches/merge/three_tier.diff http://www.skynet.ie/~airlied/patches/merge/three_tier_2.diff The first is from Dec 27th of last year, the other from March 24 this year, the three_tier_2 is probably the later patch, and I think is from some kernel like 2.6.13 or something. Neither of these do what I wanted to do but they give a lot of ideas on how to do it, the device model required in the end using a bus to do this, I actually had some thoughts about it at the X.org developers conference earlier in the year while reading LDD, but I've been swamped since and probably won't get back to it until OLS. Dave. - 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/ | ||||||||||
| Last update: 2006-05-24 07:51 [from the cache] ©2003-2008 | |||||||||||