On 5/28/06, Dave Airlie <[email protected]> wrote:
I've already pointed out to Jon the problems with this approach on
numerous occasions and to be honest do not have the time to do so
again,
I will not accept patches to make DRM drivers rely on fbdev drivers in
the kernel for many many many reasons, two quick ones :
Hence we will have no forward progress in kernel graphics for the next
few decades.
a) we don't always have a fully functional fbdev driver, see intel fb drivers.
Binding the drivers to each other does not cause any code to be called
in either driver. This is just the first step down a long path to
making the merged drivers work.
b) loading fbdev drivers breaks X in a lot of cases, we need to be a
bit more careful.
It is perfectly legal to load an fbdev driver with X today. If it
doesn't work it is a bug in X and should be fixed.
c) Lots of distros don't use fbdev drivers, forcing this on them to
use drm isn't an option.
Why isn't this an option? Will the distros that insist on continuing
to ship three conflicting video drivers fighting over a single piece
of hardware please stand up and be counted? Distros get new drivers
all the time, why will this be any different?
should I go on?
yes
You do realize that in a merged fbdev/DRM driver that if the mode
setting code is pushed into a user space library (I've said that would
be part of the path to a fully merged driver) that there really isn't
much left to a fbdev driver besides the binding and initialization
code.
I've made suggestions I've given you patches that start the work, I'm
going to finish that work, but I've no timeline, I'd hope at KS/OLS
this year to do it..
In your scheme the 60 existing fbdev drivers need to be edited to
remove their code that binds them to the hardware and make them use a
new low level driver. Are you signing up to edit all of these drivers?
I'll shut up when I see a tested patch that edits all 60 drivers and
make them use the new layer. My fear is that half the fbdev drivers
will get adjusted and no one will get around to fixing the rest,
effectively creating two fbdev architectures. A complete patch would
address that concern.
BTW, I've done patches that touched all of those drivers and it is a
very painful process. Be prepared to work on code for every
architecture supported by Linux.
--
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]
