Jon Smirl wrote:
On 5/25/06, Jeff Garzik <[email protected]> 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 [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]
