![]() | |||||||||||
Messages in this thread |
On Wednesday 24 May 2006 05:48, Dave Airlie wrote: > > > 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. Ah, okay. So I'll have to open-code the lower-level to provide extensibility... Planned on it anyway, but was hoping to be able to try and keep the lower-level a bit simpler by giving it a defined role. Not that I can reject a request to open-code something... It's what I try to request of people :) > > 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. True, but is there a way we ould pull this information from DRM? I'll have to take a long hard look and see. > > 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. Okay. Good idea. > > > 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. Okay and thank you. I'll start going through all of it tomorrow, about the same time I grab the latest kernel to start working on this. (My current limited connection wouldn't support me using GIT unless I could dedicate it for more than 6 hours. THis should be changing in about two months, but...) DRH - 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 08:13 [from the cache] ©2003-2008 | |||||||||||