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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
