> 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 [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]
