On 5/27/06, D. Hazelton <[email protected]> wrote:
On Friday 26 May 2006 17:39, Pavel Machek wrote:
> Could fb and drm simply be 'merged' into one driver (at least as far
> as rest of system is concerned)? That should have no driver model
> issues...?
> Pavel
And such was my original idea. However I've been informed that doing such
would either constitute "Breaking working systems" or "introducing a third
and unneeded driver".
For that reason I've begun doing a bit of research and planning... it might
show fruit in a couple of days.
The simplest solution to starting a DRM/fbdev merge is to declare
fbdev the bottom layer that binds to the hardware. Doing this is easy
since the fbdev drivers already contain code for binding to the
hardware. If you don't do this and instead create a new bottom layer
that binds, you are forced into modifying the 60 existing fbdev
drivers to remove their binding code and to use the new layer. I don't
see anyone volunteering to edit 60 fbdev drivers.
DRM drivers currently works in stealth mode. They use the graphics
hardware without attaching to it like a normal PCI driver would. Using
hardware in stealth mode is a bad design, but DRM can't be modified to
attach to the PCI device because it would conflict with the fbdev
driver that is already attached.
So, the easiest way to fix this is to change the eight DRM drivers in
the kernel so that they are linked to their corresponding fbdev
driver. After these changes you would not be able to load the DRM
drivers without also loading their corresponding base fbdev driver.
The embedded people are still happy since they can load fbdev and
ignore DRM. Note that you can use symbols to create a dependency
without changing the existing functions of either driver.
Making the drivers dependent starts us down the path of a full merge
and having one driver in control of the hardware. As part of the basic
merge patch I would also move the drm directory from drivers/char/drm
to drivers/video/drm. After this very basic linkage is established you
can start making real changes.
BTW, I have already submitted a patch that does this and it was
rejected. I might be able to find it somewhere, but the dependency
code is not very hard to write.
--
Jon Smirl
[email protected]
-
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]
